Re: CSS21 @font-face removal

On Monday, November 3, 2003, 11:37:28 PM, David wrote:


>> As a graduate student in graphic design, please understand that I don't
>> grasp all the nuances of why embedded fonts must be active with a user's

DW> I didn't understand "active with user's system".

"Installed", basically, but with the extra nuance that (due to
historical limitations on number of installed fonts on some OSs) its
common practice in the professional graphics design community to have
a large number of fonts actually installed but to switch on as
'active' certain groups of fonts, leaving the rest inactive and not
showing up on font dialogs. The fonts selected depend on what work is
being done and will change from one client to the next.

>> system when SVG and SWF can embed font sets, but my point is more broad.

DW> The primary problem with SVG is that IE dominates the market but development
DW> has been indefinitely frozen.  I suspect that they never intended to
DW> support SVG even before the freeze.  In addition, the EOLAS patent work
DW> around in IE will make it difficult to use plugins.  Flash will also
DW> be hit by EOLAS, but MS do distribute the plugin.

That's one problem, sure. The fact that browsers do not have an
extensible and modular architecture but rather a monolithic one, is a
more fundamental concern.

DW> As regards fonts, the SVG native font system lacks hinting, so is not
DW> suitable for high quality fonts in normal type sizes (based on SVG 1.0
DW> CR02).

CR02?

Yes, SVG fonts in SVG 1.0 and 1.1 do not have hinting.

There are two methods of compensating for the highly deficient
resolution of current screens, one is by antialiasing (multiple
samples per pixel) and the other is by hinting.

Hinting works well when the text is small, high contrast, when
legibility is more imporant than design fidelity or typographical
color and when the type is set at integer pixel sizes and is aligned
to the pixel grid of the screen.

Slightly rotated text, for example, gets no benefit from hinting. Text
which is being animated looks very weird if it suddenly has a
discontinuous drastic change in appearance just because it became axis
aligned or hit an integer pixel size.

DW> As that document says, there was no standardisation of font
DW> formats for CSS fonts.

Correct, until SVG produced one.

DW> If you did extract the outline of a high quality font and encode
DW> it as an SVG font, you should expect a cease and desist order from
DW> the font's owners.

Please back that up with an appropriate citation if you wish to state
it as a general principle, and state which country's laws you are
making your case for and which font license.

DW> Whilst I don't know the exact support in Shockwave Flash,

It "extracts the outlines of a font and encodes it"

DW> being a closed format makes it easier to embed quality fonts, as
DW> you can make reasonable claims that you are preventing viewers of
DW> the page from extracting the fonts and using them elsewhere.

Pshaw.

DW>  This is also why PDF can have embedded
DW> fonts (even though authors often forget to embed them).

Sorry, that is a really poor argument. PDF (and presumably SWF if
someone has enough documentation to decode it) is no harder or easier
to extract fonts from  than any other format that allows font
embedding.
 
DW> The particular problem with CSS fonts is that they are separate from
DW> the document, and in order for the font foundaries to allow their use,
DW> a means has to be provided to stop people simply attaching them to
DW> a completely different document on a completely different web site.
DW> Unfortunately, this also tends to break their use on local copies of
DW> the document or on CD's etc. (although you can probably authorise them
DW> for file:///a:....file:///z:)).

That comment is specific to particular implementation, and not as
general as you make out.

A more general rule would be to say 'consult the license of the font
you intend to use'. Some fonts allow installable embedding, some allow
print and preview, some disallow all embedding. Some allow embedding
as long as the font is unchanged; others only allow it if it is
changed (subsetted, hints removed, etc). So, read the license, on a
case by case basis.

>> Most of the work I do with identity systems depends heavily on 
>> typographic consistency across all media, and often I start an identity

DW> This is what page description languages, like PDF, which has had 
DW> embedded fonts since before the web, are intended for.  Using SVG for
DW> this would probably be worse than the current versions of PDF, as they
DW> have accessibility features, to allow the underlying structure to be
DW> represented, that are not present in SVG.

Again, you would need to back up that claim.

DW> To get accessibility in SVG, you would have to send as XHTML and
DW> use a client side XSLT transformation to turn it into SVG for
DW> rendering.

Thats pure nonsense, infeasible in general, and mere mud slinging.

DW>  (SVG does have some accessibility
DW> claims, but I believe they are rather weak in practice.)

XHTML and PDF also have some accessibility claims; I would be
surprised to hear anyone claim that anything you do with them is
'accessible'. As with most things, it depends what you do and how you
do it.

DW> (A subset of SVG could be considered to be an XMLised version of 
DW> untagged PDF.  Tagging is the feature that allows reflowing, etc. as
DW> needed for accessibility and PDA display.)

Actually you can design your SVG that way too, so all the text is
available in a sensible reading order to a screen reader. Naturally,
SVG is 'tagged' already ;-)

In addition, I think the original poster was asking about using SVG
fonts more generally, including with flowed text.

>> system with the design of a specialized font for the client. It is 
>> nearly impossible, without font embedding tools from Microsoft and the

DW> Are you using these in anger,

Since he said it was nearly impossible, then probably not.

DW> as my impression is that hardly any one actually uses font
DW> embedding, which is probably why there was no priority to
DW> implement it in Gecko (the core of Netscape 7)

Not including the Bitstream PFR renderer in the open-source Gecko was
due to licensing and source-availability issues, plus the fact that
Netscape 4 never implemented the CSS2 WebFonts spec anyway but iused a
LINK element in HTML.


DW> and therefore why it has been dropped from CSS2.1.

The old, tired, 'there are two implementations in the world' argument.
Sigh. Hey, its 1998 already, must have dozed off for a while there....


DW> Removing it from CSS2.1 will not, of course, remove it from IE.

Or, indeed, the other implementations.

>> Will SVG work to solve this solution, or has the Web taken a huge step

DW> SVG solves a different problem from that solved by HTML.  It is an
DW> image format, and so, for documents, is only suitable for final form,
DW> print image, documents (one implication of this is that one has to side
DW> scroll them to read them if you need to enlarge the font).

SVG is only suitable for print image documents. I see. remind me to go
tell SVG developers list to stop what they are doing, they have it all
wrong.

>> backward by deprecating @font-src:url? I can't tell if SVG is simply a

DW> As I understand it, it has not been deprecated,

Not formally. Moving from Rec to working draft over five years is a
fairly effective means of deprecating something in practice, though.


DW> it has simply been
DW> deferred until there is widespread support.  If you could convince people
DW> to use them, embedded fonts would be essential to a proper separation of
DW> form from content, as they allow a very straightforward textual content
DW> to have tightly controlled fonts,

This is a good point. To reiterate: instead of some inaccessible html
table holding slice and diced images some parts of which look like
text (that would be the always-accessible XHTML that's needed for
accessible SVG, I guess) your content contains text that is, in fact
text - searchable, indexable, translatable, updatable text. You then
apply fonts to it in a separate process.

DW> and they allow scaling of those fonts.
DW> (The major problems with GIFed fonts is that users cannot override
DW> the size - quite important these days as a large number of sites set
DW> unreasonably small fonts sizes - and can't override the face, in order
DW> to make them easy to read.)

This is one drawback, true. I wouldn't say its the major one, by a
long shot. All those HTML pages with headings, sidebars, etc set as
GIF text have the problem that the text cannot be searched, Google has
no idea its there. Localization people get a bunch  of images and have
to mask out the text, patch it up, and put text in a different
language on top. Dynamic modification of text in images is time
consuming and expensive.

DW> Note that the idea that the end user can reduce a document to its
DW> content and style that for their own convenience may be anathema
DW> to the concept of a house style, but it is, I believe, a fundamental
DW> tennet of the W3C, and even in non-W3C media it is becoming a legal
DW> requirement in many countries, as result of disability discrimination
DW> legislation; this is why tagged PDF was developed.

Tagged PDF was developed because the text was typically not in a good
reading order and was often split into very short runs, for example
for kerning. In SVG, you can select a good reading order; you can have
long text runs (even if the text has kerning) and thus, a reader that
accesses the text via the DOM can get at all of it. Its tagged
already. It doesn't need to have a separate, alt-text-like, tagging
bolted on.

DW> PS  The SVG people will probably say that I've understated its 
DW> accessibility and ability to handle zooming gracefully.

I would have, but you beat me to it.

-- 
 Chris                            mailto:chris@w3.org

Received on Monday, 3 November 2003 18:45:49 UTC