Hi Hans, does it relate to the ToUnicode object only, or something else as well? I think the ToUnicode object can be generated by pdftex, as pdftex knows the current encoding vector and can find out the corresponding unicode for a given glyph name by looking into the AGL? It would also save some space, as fonts having the same encoding vector (eg 8r.enc) can share a single ToUnicode object. But I am not sure, have to recheck the ToUnicode description. Postponing the object refered by \pdffontattr is not that easy to do, as pdftex does no parsing of the parameter of \pdffontattr (like in case of many other parameters). Thanh On Mon, Aug 15, 2005 at 01:04:07PM +0200, Hans Hagen wrote:
Hi,
There are situations where unused resources can end up in a pdf file; think for instance of a font system that sets up tounicode vector inclusion. For practical purposes, one needs to have a font loaded before the document preamble is scanned. If not, it is impossible to deal with certain dimensions. So, it that case, we have something
\pdffontattr\font{/ToUnicode ... 0 R}
But imagine that we never use that font. If the rest of the document fonts use the same vector, this is no problem, but when we switch to another font encoding, we end up with a non used to unicode vector. Or think of docs with only graphics (or other pdf pages) where no such vector is needed.
Because the object reference ... 0 R is not seen, pdftex cannot decide either or not to include the object, so we need to use \immediate\obj which result sin the non wanted entry. A solution is
\pdffontvector <obj num>
but a more generic solution is
\pdffontattr\font{/ToUnicode ... \refobjnum <objnum>}
which will tag the object (number) as being used but only when the font desciption object is really flushed (so \refobjnum fullfils a signal function)
this means that a (later) \pdfobj{...} will not be flushed when it is not really refered
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
_______________________________________________ ntg-pdftex mailing list ntg-pdftex@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-pdftex
Thanh Han The wrote:
I think the ToUnicode object can be generated by pdftex, as pdftex knows the current encoding vector and can find out the corresponding unicode for a given glyph name by looking into the AGL? It would also save some space, as fonts having the same encoding vector (eg 8r.enc) can share a single ToUnicode object. But I am not sure, have to recheck the ToUnicode description.
sharing is not the problem (just a matter of housekeeping in tex), but it makes sense to do it directly in pdftex (maybe this code can be shared with dvipdfmx)
Postponing the object refered by \pdffontattr is not that easy to do, as pdftex does no parsing of the parameter of \pdffontattr (like in case of many other parameters).
sure, but was thinking of some clever mechanisms similar to the substitution mechanisms in dvipdfmx specials; it parses for @whatever kind of object references (placeholders) and resolves them; it could even be a generic mechanism: \pdfannot|obj|etc objref somestringa ... {...@somestringb...} \pdfannot|obj|etc objref somestringb ... {..@somestringa...} no stream parsing, just resources, attributes, object and annot content using something \pdfobjref{...} may be safer since that can expand to something that does not clash \pdfannot|obj|etc objref somestringa ... {...\pdfobjref{somestringb} ...} \pdfannot|obj|etc objref somestringb ... {...\pdfobjref{somestringa} ...} think of internally "objref something" resolving to <magic prefix>something and "\pdfobjref{somestringa}" to <magic prefix>something as well pdftex keeps track of numbers itself then; i'm not sure how dvipdfmx does it but if it involves a second pass, just forget about it; i'll find a way around it -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Thanh Han The