[Devel] Re: FreeType -> PS/PDF

[Leonard Rosenthol]

At 05:37 PM 12/24/2001 +0000, Vadim Plessky wrote:
> Will the license be compatible with FreeType and/or BSD?

        My rewrite would use the FreeType license, since I'd add it to the 
FT CVS repository (assuming David doesn't mind ;).


> What kind of license your former employer is using?

        None, it's proprietary.  Part of the reason to rewrite it.



> Embedded font is PS Type3 font, so all TrueType hints are lost, and there are
> no PS hints generated.

        Yuch!  Not only don't you have hints, BUT you also get (as you 
noted) really crappy screen display.

        The Type3 conversion hack is quite common in the Unix PS 
generation community - probably going back to the need to do that with 
TeX's MetaFonts.  It is also a "cute hack" to provide subset embedding w/o 
actually implementing real subsetting.


> [NOTE: I remember that David Turner wrote some time ago that Acrobat 5.0 uses
> new different algorithm for auto-hinting of PS fonts, and ignores hints for
> embedded fonts; I haven't tested Acrobat 5.0 and can't confirm this, but
> overall it seems quite realistic and reasonable ]

        News to me if it's true...Acrobat (and Ghostscript and Xpdf) all 
uses the embedded data (if present, of course) to display the font.  So if 
the hinting data is present, it will be used.  Of course, it is certainly 
possible to skip that data when embedding it, especially if doing subsetting.


> It worth to mention here that, according to that thread and some posters,
> some PDF-generating software positions *each glyph individually*, therefor
> you can't just "copy and paste" text - as it's required by WCAG (Web Content
> Accessibility Guidelines)

        The two are NOT related.

        It is certainly true that some PDF generators position glyphs 
individually - especially ones doing "high end" typographical functions 
like kerning or tracking.  HOWEVER, that doesn't mean that you can't copy & 
paste.

        When Acrobat and Xpdf display a PDF, then do some pretty complex 
stuff to reorganize the physical (in file) ordering of the glyphs into the 
logical (on screen) ordering so that text selection & extraction happens 
correctly - regardless of the source data.  Ghostscript's text extraction 
does similiar things, though not as complex since it doesn't need to worry 
about "live selection".



> So, embedding some text in PDF (and/or SVG) doesn't offer you warrantry that
> you can retrieve text later (for reading via some Screen Reader, for example)

        If does for a properly written tool.  In fact, Acrobat 5 for 
Windows directly integrates with Screen Reading software to present it with 
logically ordered data that it can use.  It will also use, if present, 
structure information so that a table, columnar text or other complex 
layout is read in the logical order for the user.


> and, as I mentioned above, for Accessibility as well.
> I am not big expert in Accessibility so far (but working on improoving my
> skills), but if we finally come to some open-source SVG-to-PDF or
> 2D-graphics-with-text-to-PDF generator, I think we should take care about
> blind people or people with visual disabilities in advance.

        Agreed!

        The way to do this for PDF is to use the new features of PDF 1.3 
and 1.4 to add "structure" and "tagging" to the file.  This is what then 
allows screen readers to read the file in the best possible way.,


> It will not cost a lot of extra code but can make thousands, if not millions,
> of people happy!

        Doing structure and tagging isn't rocket science, but it will 
require some interesting code. Which is why you don't see anyone (other 
than Adobe) generating this stuff - yet...


> Still it seems Adobe added several extra libraries for their SVG 3.0 viewer
> (I refer here to Linux version of it):
> address@hidden adobesvg-3.0]$ ls lib*
> libACE.so  libAGM.so  libBIB.so  libCoolType.so  libNPSVG3.so  libSVGCore.so

        ACE is the "Adobe Color Engine". I'm not familiar with BIB, but 
I'll ask around...


Leonard