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

[Jonas Petersson]

Hi again,

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

So, if I'm right about this, the problem I experience it a combination
of 2 (or 3) issues:

* 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 - which is the
reason Fred's pdf works regardless.

My best guess is that the whole wordspace issue must stem from a basic
problem that spaces are not drawn (since they are invisible), and this
is the real root cause of it all - but there is little that can be
done about this. Presumably, a lot of the time each word (or even
character) is positioned individually and therefore spaces are usually
never considered. I've not dug into this, but suspect distiller
handles this in a special way.

In my particular case, spaces are drawn - here is a sample snippet
from the PS code:

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.

Matthias, what do you think about my theory?

                                                  Best / Jonas