Re: CSS21 @font-face removal

> 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

Only to the extent that you can also design PDF that way without any
need for tagging.  Good reading order is a wetware problem; most PDF I
have seen already has a good order (most HTML home pages have, at best,
questionable reading orders; this is more to do with the nature of
the documents I see in the two mediums).  The risk is that web pages are
good candidates for paste up design styles, and combined with WYSIWYG
authoring tools, the result will be paste up order documents[1].

> available in a sensible reading order to a screen reader. Naturally,
> SVG is 'tagged' already ;-)

Tagged PDF would be like sending both the SVG and an XSLT transformation
to convert the contents to HTML; it allows HTML type element to be
overlaid on the presentational page description.  The elements are
clearly based on HTML elements.

(It's the opposite of the HTML/style sheet model.  The latter model takes
the logical structure as dominant and tries to create a presentational
form from that.)

> 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

But PDF documents typically are in a good reading order!

> for kerning....

This is not a fault of PDF, it is a fault of the authoring tools.
As such, one would expect any attempt to create SVG with the same tools
would suffer the same problems, and any fix for SVG to also be available
to PDF.  Kerning is not the problem, it is that, at least on Microsoft
platforms, software microspaces by outputting each character separately
and not outputting spaces at all.  The PDF TJ operator would allow them
not to do that, as it identifies a continuous string but allows any gap
between characters to be tweaked.

Tagged PDF doesn't address this issue, although addressing it is a 
pre-requisite for tagged PDF.  Addressing this issue requires the
authoring tools to obey long standing PDF authoring rules which are
generally breached, because the tools are only interested in controlling

Tagging proper starts adding the ability to determine the difference
between soft newlines and those introduced for list items, headings,
paragraphs, etc....  Full tagging allows you to recover the structural
HTML equivalent, which could be presentation free HTML if the author
and authoring tools were so minded, even if that is unlikely.

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

Also true of PDF, if generated correctly.

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

The Actual Text attribute in PDF is only needed when text is not
actually used.  The same will be true in SVG if people pre-image text
to achieve special effects, e.g. they use Microsoft Word's Word Art to
create the text.  It always was a design aim of PDF that text should be
text and therefore recoverable.

I think you are comparing what SVG is capable of doing with what people
actually do with PDF.

[1] tagged PDF is not a panacea, as it still requires the author think about
reading order and thinking about reading order may allow the physical
order to be good, without requiring a conflicting logical description, at
least not just for reading order.

Received on Monday, 10 November 2003 02:12:28 UTC