Re: [Swftools-common] Spaces disappear for some pdfs

[Matthias Kramm]

On Sat, Dec 20, 2008 at 11:56:26AM +0100, Jonas Petersson <address@hidden> 
wrote:
> I've did some further poking around the code and I may be wrong, but
> there appears to be a bit of a gray area of responibility when it
> comes to outdev and fonts.
> 
> If I read the code right (not too sure about that really), xpdf
> certainly has a bug in that it assumes that a space is always
> represented by a " ", but in the case I have gs seems to have used
> ?\0'  (let's assume gs is correct for now).

Yep. Even though only gs does that, Distiller doesn't. So this may
also be a bug in gs, for which Acrobat (as opposed to xpdf) contains
a workaround.

> However, the state->getWordSpace() call makes use of font information
> that appears to come from the fonts provided by the outdev which is
> part of the swftool stuff.

Isn't wordSpace set by opSetWordSpacing() in Gfx.cc?

> * xpdf assuming space always stored as " "
> * swftools outdev fonts providing wordspace as 0.
> 
> The third issue is of course the use of '\0' for space

Indeed. And \0 maps to .notdef, which has zero width.
This whole thing *may* be just an encoding problem.

> 275.528 408.945 mt 0.000 rotate <5965732c006974277300706f737369626c6521> show
> 
> Decoded from hex the string is:   "Yes ,\0it's\0possible!", so the use
> of \0 for space is actually not gs', but the tool that produced the
> PostScript code - and that code certainly works on printers as well as
> in Acrobat regardless of whether it went through gs or distiller.

Yep. Interestingly enough, as pointed out by Derek, ghostview is also able to
display the pdf correctly. So it may be worthwhile to dig into the gs
code.

Greetings

Matthias