RE: New work on fonts at W3C

On Tuesday, June 23, 2009 9:24 PM Brad Kemper wrote:
> 
> On Jun 23, 2009, at 3:25 PM, "Levantovsky, Vladimir" wrote:
> >> Brad Kemper wrote:
> 
> >
> >>
> >> I really wonder if you are being genuine when you say things like
> >> that. I see absolutely no reason whatsoever why the tool to split a
> >> font in two, rename it, and add a little license info should be any
> >> more difficult or less automated to use than a tool like WEFT for
> >> creating EOT. It might even be a little easier, since it would also
> >> generate the @font-face code block and maybe a sample font-family
> > rule.
> >>
> >
> > Brad, I am brutally honest with you here.
> > I said what I said because I know how difficult this can be. For
> > example, in Arabic each character [...] It gets a lot more complex
> > for South Asian languages, and even
> > Latin-based languages may use fonts that support these advanced
> > features.
> 
> 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. 

> 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. 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. 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, ...] 

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.

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 keep
track of all the original font files and those that are renamed. 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.

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. 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 so that browser vendors don't need to
support a new web font wrapper that can make all fonts really easy to
use - 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.
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, and I cannot even
imaging font vendors doing this. 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. I see this as an attempt to
disenfranchise commercial font vendors, and I find it unacceptable.

> 
> 
> > The browser would then do the same (only in
> > opposite direction). You do not need to analyze the content of the
> > font
> > and do all other complex things you suggested in your previous post.
> 
> I presume that here you are referring to my comments about CORS, even
> though I really only meant in my latter posts that any lookup on the
> font would occur once, when you were adding the font to the server and
> transfering licensing info to the part of the server that generated
> CORS headers.
> 

I was referring to a simple obfuscation proposed by Ascender and to your
proposal for font splitting, it had nothing to do with your comments
about CORS.

Received on Wednesday, 24 June 2009 04:34:20 UTC