Re: New work on fonts at W3C

On Jun 23, 2009, at 9:33 PM, Levantovsky, Vladimir wrote:

>> Now see, this is why it looks to me as though you are trying to avoid
>> the question intentially, in order to maintain the myth about my way
>> or Daggett's way being so much more difficult for site authors than
>> EOT. I asked you about that specifically, stating once again the  
>> fault
>> in that logic (it's been in several posts now, and not just from me),
>> and instead of addressing that point you re-answer an earlier point.
>
> You asked me specifically about a hypothetical font-splitting tool  
> that
> doesn't exist and IMO wouldn't work - and I answered your question
> truthfully and based on the facts, trying to explain why it wouldn't
> work.

No, you said "I am also stunned that you seem to be suggesting that  
web authors should go to such a great length and make extra efforts in  
handling fonts."

Whether or not a tool creating programmer could create a tool that  
worked is not the same as Web authors using the tool. Your comment was  
about Web authors using the tool, and mirrors your other unsupported  
comments about a tool that renames a font and adds some licensing info  
to it (John Daggett's idea). While I can accept that font-splitting is  
unfeasible, I am stunned that you keep saying that the use of one  
hypothetical tool would be harder to use by Web authors than WEFT or  
another hypothetical tool, when all such tools would required about  
the same level of inputs.


>> It really seems like a deliberate choice to not give a rational
>> response to a point you've yet to answer or explain, this insistance
>> that one tool would be more trouble than another to use, without any
>> rationale for why it would be, and which on the face of it seems an
>> absurd point of view. Thus, I'm sorry, but I have to question if you
>> are really here to discuss the issues, or just to push an agenda.
>>
>> Please explain why you think there would be more hoops for a tool  
>> that
>> does even what John Daggett described than there would be for using
>> WEFT or similar.
>>
>
> Okay, I didn't realize that the second part of the question was
> independent of font splitting.

It was in response to the part about being stunned that Web authors  
(using an automated tool) would have to go to great lengths and make  
extra efforts in handling fonts. Whatever the tool does, I never said  
anything to suggest that it would be any extra effort from Web  
authors, whether it was a font splitting tool (that we now know  
wouldn't do a good job and is impractical), a font renaming tool (J.  
Daggetts's idea), or a tool to turn your font into bars of gold- 
pressed latinum.

> Here is what I think:
>
> 1) First of all, WEFT isn't an ideal tool. I am sure that if EOT spec
> had been publicly disclosed earlier, there would have been better  
> tools
> available.

I agree with that.

> For example, the simple implementation could be just a
> command line utility that would be extremely simple and easy to use,
> something that would look like this:
>
> convert2eot <font_file_name> [/my_domain_name1, /my_domain_name2, ...]

LOL. OK, you consider a command line easier to use than an GUI. To  
each his own. But OK, fine, whatever floats your boat. I would imagine  
more than one tool, for people with different preferences.

> 2) Let's assume that you also have a tool that renames the fonts as  
> John
> suggested, and this tool is a simple command line utility:
> renamefont <font_file_name> "No trespassing - licensed by XYZ Corp"
> On the surface - it's a wash, an author just needs to run a tool and
> type a new name.
>
> 3) However, the use of renamed fonts will affect normal @font-face
> workflow. When you use a real font name, the UA would usually look  
> if a
> font is available, and only if not found, it would download a resource
> specified by @font-face-src. Renaming fonts will force UA to always
> download a font, even if identical font is installed.

No, you can have it look for one or more locally installed fonts of  
other names first. If it finds one, or if it downloads one, it can  
then associates that font with a short, simple font-family name of  
your choice (and it could be something like 'Garamond', if you wanted  
something that might still work somewhat in UAs without @font-face  
support).

> Typically, web authors use more than one font family for their content
> (where each font family may include multiple font files representing
> different styles and weights) - authors would have to manually  
> keeptrack of all the original font files and those that are renamed.

That does not need to add any more difficulty than it does for EOT  
tools that create a new copy. We talked before about how the tool  
would likely create the @font-face block so that the author only had  
to paste it in. Here is a hypothetical example:

@font-face {
   font-family: Garamond;
   font-weight: normal;
   font-style: normal;
   src: local(Garamond),
           url(/fonts/Garamond/Normal/Licenced_Only_To_XYZCorp.ttf) ;
   /* Note:  Any font on this page listed as   
'Licenced_Only_To_XYZCorp.ttf' is
   licensed only to XYZ Corporation with limited rights to post on a  
limited number
   of Web sites, as stated in the terms of their license, which can be  
referenced at
   http://www.licenseterms.com/lookup.php?guid=123abcxyz */
}
@font-face {
   font-family: Garamond;
   font-weight: bold;
   font-style: italic;
   src: local(Garamond),
           url(/fonts/Garamond/Bold_Italic/ 
Licenced_Only_To_XYZCorp.ttf);
   /* Note:  Any font on this page listed as   
'Licenced_Only_To_XYZCorp.ttf' is
   licensed only to XYZ Corporation with limited rights to post on a  
limited number
   of Web sites, as stated in the terms of their license, which can be  
referenced at
   http://www.licenseterms.com/lookup.php?guid=123abcxyz */
}

> In
> addition, I suspect an author's ability to use other CSS properties  
> like
> font-style, font-weight, etc. may be affected by font renaming.

I don't see how.

> You see, it's not just the matter of whether it's easy or not to use a
> particular tool - it is how this particular requirement would affect  
> web
> authors' workflow.

A tool that generates the @font-face block (in in the example above)  
could actually be easier to use because of that. I don't see any  
negative impact on workflow so far, and nothing significantly worse  
than with other wrapper-based solutions (where you'd still have to  
keep track of where your new copies of your fonts are, and what they  
are called).

> This is why I consider this an extra burden for
> authors, and I don't see any reasonable justification for it, except
> that all web authors should suffer

No suffering or burden that I can see.

> so that browser vendors don't need to
> support a new web font wrapper that can make all fonts really easy to
> use -

...so that you can start using this right away, without waiting for  
brand new (and controversial) formats to go through a standardization  
process and implementation years from now. A wrapper format would not  
make the fonts any easier to use (not in any significant way that I  
can see from your explanation).

I am a Web author, and I would prefer the John Daggett way. Just so  
you know. Maybe at some point in the future a wrapper format could  
eventually take over if it could do the compression in a way that was  
a significant improvement over other methods, and was well supported,  
and was still needed at that time. But your ease of use arguments  
aren't holding much water so far.

> seems totally unfair to web authors.
>
> It is also unfair to font vendors. We all know how business is done on
> the web - every extra click that your visitor (i.e. potential  
> customer)
> needs to make, or every extra second it takes for him to find (or to
> get) where he wants to go means losing visitors and losing business.

  agreed.

> This is the same for font vendors - any requirement that font vendors
> would have to impose on potential customers (in this case on web
> authors) would guarantee losing their business,

Again, I still do not see what extra requirements you are talking  
about that would go beyond what you'd need to do for a wrapper format  
or EOT.

> and I cannot even
> imaging font vendors doing this.

I also have my doubts about the ability of large old foundries to  
quickly take advantage of this current capability and new market too,  
but not for the reasons you mention.

> In this particular case, it also gives
> an unfair advantage to those authors who would opt to use free fonts -
> they wouldn't have to do anything.

They already have that (minor) advantage. How is a new format for  
wrapping the font with some licensing info going to change that? UA  
support for raw free files would not go away.

> I see this as an attempt to
> disenfranchise commercial font vendors, and I find it unacceptable.

Seriously? You're questioning my motivation? You think the reason this  
is getting getting so much discussion is because we all want MonoType  
and Adobe to fail? Come on.