On 03/06/2012 07:29 PM, Chris Bowditch wrote:
On 06/03/2012 11:08, mehdi houshmand wrote:
Hi Mehdi,
Font de-duping is intrinsically a post-process action, you need the
full document, with all fonts, before you can do any font de-duping.
PostScript does this very thing (to a much lesser extent) with the
<optimize-resources> tag, as a post-process action.
At least that is transparent to the user, but re-parsing the input is
a sub-optimal solution as it incurs a performance penalty so we should
investigate if there are alternatives first. I can't recall why the
Postscript Paintewr/Renderer was architected in that way but thats a
separate topic.
At a guess, because PostScript is much less capable of non-linear
references and access than PDF is. It's more expensive and slower to
forward-reference resources because PostScript has to parse and execute
all the rest of the document to find the resource it wants, while PDF
just seeks to the object at the byte offset referenced in the xref table
and reads only the object it requires.
The requirements are perfectly clear: Given a set of input PDFs,
XSL-FO, create a single merged PDF with a consistent and unduplicated
set of fonts. Why would there be slight kerning differences if the
assumption that the font name is unique holds true.
Assuming the font name is unique is dangerous, since it's provably true
that in the wild there are numerous subtly (and sometimes grossly)
different fonts with the same name.
The font dictionary contains glyph metrics information that along with
the font name, slant, weight etc can be used to match the font rather
more closely. For extra caution, checksums of subset glyphs can be done
to make sure they're *identical*, but honestly that's unnecessary if the
metrics match.
If that assumption is wrong then I agree with what you say. Ultimately
that should be down to the user though, they know their fonts, so they
can decide whether to merge them or not via a setting in the
fop.xconf. Your argument is not sufficient to say this approach should
never be used. It brings a lot of benefit to users who know their font
names are unique.
It should be safe to do automatically and transparently by default,
because only partially overlapping subsets of identical fonts should
ever be merged. Anything else is a substitution not merging duplicate
subsets, and has entirely different considerations because of the
possibility of visible changes caused by non-matching metrics etc.
--
Craig Ringer
