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