Hi,

Well yes, but then s/he has to be prepared to use appropriate translation 
methods to get what is wanted from what is supplied, but the author and browser 
software.

That is a standard problem: It'd be most efficient, if the author supplied one language and the user could reliably translate it by electronic means into the desired language. Unfortunately, translating is a hard problem of IT, so the quality is best, if the author or other translaters do that job.


The best that can be expected is that unusual representations of data be tagged 
as such, so that software has a chance to recognise that it may not be as 
straight-forward as just the letter content might suggest.
Unfortunately (again), not everybody has a google center at service, which can effectively detect these representations and find alternatives automatically.

Then attributes to the tags can supply alternative representations, if the author has sufficient forethought to predict that someone might want to use these. But there should be no obligation to have done so, as an author cannot be expected to predict all the possible uses that someone may make of his/her written ideas.

Maybe my use of "should" was wrong (my mother tongue is German): I didn't mean it as an obligation but as a necessary mean for rich communication. Both sides have a mutual interest in as rich a communication as possible, at least in noncommercial settings.

Thus we are led to appreciate the need for Tagged PDF.

That's the least variant. I could think of even richer ways of communicating. E.g. wiki-pages with professional typography.



If you want them to get  "Louis XIV"  then no /ActualText is required.
*unless* that X I and V are really: U+2169 U+2160 U+2164 .
In that case you may want the /ActualText  to replace with "XIV" so that
your readers don't end up with the undefined character symbol.
As Unicode says: these Codepoints are deprecated. So the letters XIV should be 
prefered. (And I'd still say, that the number 14 is preferable.)

Deprecation is a curious thing.
At what level should it be implemented or imposed?

Should TeX stop an author from using these symbols?
If they do get into a PDF, should the browser refuse to display them, 
substituting something else?
Or if a reader does a Copy/Paste, should either the copying or pasting 
application offer to make a substitution?

I'd answer  No, No, Perhaps  to these questions, otherwise it becomes 
impossible to even put into print that the specific characters should no longer 
be used.

Of course not. Why should any application do this? I mostly read these standards positively. As long as no alternatives exist, deprecation is no issue.


So one might want a package, which offers a macro \romannumeral{14}, which 
produces the glyphs (intended to be used by the font author) and adds 
appropriate PDF-specials whose content is based on the active language. At 
least, it should offer option keys to set these contents by hand e.g.

Louis \romannumeral[screenreader="katorze",replacement_text="quatorze", 
use_font_symbols]{14}

Someone would define a macro  \LouisXIV  to expand to this kind of thing.
An author just puts the macro into his/her LaTeX (or ConTeXt) source.

I don't like to put such code into my documents, as I regard the problem as more general demanding a more general solution. Till then, I'll have to accept it.

There is a lot more for authors and macro-writers to think about and use.
Yes, the intention is to much more effectively convey meaning within electronic 
documents.
And authoring tools should help doing it.


BTW, if you have Acrobat Pro 10, then I can show you some PDFs with fully 
tagged, quite complicated mathematical formulas. You'll need the Pro version of 
the browser to be able to see the tagging, and extract the content as XML 
incorporating MathML. No other software can do this yet, to my knowledge — 
oops, not true: the MathPlayer plugin to Adobe Reader should be able to do it 
also.
Copy/Paste from these PDFs gets all the correct math symbols — using Plane 1 
alphanumerics, where appropriate — but cannot sensibly position superscripts, 
subscripts, fractions, etc.

I use Ubuntu 11.04 with evince and on occasion Adobe Reader 9 for that OS. So no Adobe Reader 10 or anything "Pro" from Adobe.


Maybe in a year or so, when TeX support for Tagged PDF has become more mature.
At present it is very much experimental.

I have a lot of tea.

bye

Toscho


--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Reply via email to