the errant postscript looks like so:
begin /g0051 81 def end pop pop 16 522 <0001001604450296054c0019006e4043 a70fb902b60f038907860f861303760f 77138b020366137a027907036a026907 640f039902960fa80203000134118109 770c0d168104040d000c680f0d1f0d2f 0d030db80170b7006801191a58de182b 4e10f44dedfd5ded003f3c10ed103cf4 fdf43c3130015d5d5d5d5d5d13233636 33321716163332363733160606232227 2626232207063620046a4e29222da528 20310e1f01335d2f4f753f2c1529180b 0449897a0d116d36555d6d3d502b1224 1100> /TimesNewRomanPSMT findfont exch 1 index havetype42gdir {/GlyphDirectory get begin 215 exch def end} {/sfnts get 4 index get 3 index 2 index putinterval pop} ifelse /CharStrings get begin /g00d7 215 def end pop pop 13 4990 <ffff000c000003f7054c022600510000 010700d700ab00000021401301404150 419041035041014102d2482b010145b9 02ad0029002b012b715d3500> /TimesNewRomanPSMT findfont exch 1 index havetype42gdir {/GlyphDirectory get begin 120 exch def end} {/sfnts get 4 index get 3 index 2 index putinterval pop} ifelse /CharStrings get begin /uni00F1 120 def end pop pop /uni00F1 glyphshow
Perhaps another idea would be to keep multiple tables of booleans about whether they were downloaded, one for /uni definitions and one for non unicode anonymous glyph /g definitions?
On Tue, Sep 9, 2014 at 2:25 AM, Daniel Horn danielrh@dropbox.com wrote:
I have an example where that's not the case where an ñ comes first It downloads a *composite* character which, as far as the pdf is concerned, is just a very complicated set of strokes that looks like a ñ. But while it looks up the n to draw those strokes, the actual definition of the n itself is *not* in the resulting .ps file (I checked it by hand) It only defines the ñ as a font subset, and then all subsequent n's come in as squares.
The problem is only encountered when composite unicode-named glyphs are being downloaded. Thus the bug is only being triggered when patch 2/3 is applied but patch 1/3 solves it.
On Tue, Sep 9, 2014 at 2:17 AM, Huw Davies huw@codeweavers.com wrote:
On Mon, Sep 08, 2014 at 09:18:51PM -0700, Daniel Horn wrote:
Fixes a bug with caching composite unicode glyphs (if a ñ came before any n in the document, then all subsequent n's would appear as a box) This was because the glyph was marked as having been sent down when it was only a component of a more complex glyph
This shouldn't be necessary, I suspect something else is going wrong. If the 'n' has been downloaded as part of a 'ñ' then it really shouldn't be necessary to download the 'n' again.
Huw.