[Okular-devel] [Bug 208121] incorrect space characters in pdf form

[atayoohoo at googlemail.com]

https://bugs.kde.org/show_bug.cgi?id=208121

--- Comment #21 from atayoohoo at googlemail.com ---
>> From user point of view inconsistent behavior (no squares in pdf view, but squares on print)
>> is definitely a bug, not a feature. Is it possible to make okular rendering on screen
>> and rendering for printing consistent (both with squares or both without)?
How to render the notdef glyph is not that clear.

To get a space, replace "./notdef 0 def" by "./notdef 3 def" in line 686 of the
postscript output.

Quotations from http://bugs.ghostscript.com/show_bug.cgi?id=690935 (the same
problem like here).
[Comment 9]
The default behaviour for Ghostscript is to render TrueType /.notdef glyphs
when
the input is PostScript, and *not* to render TrueType /.notdef glyphs when the
input is PDF. Hence why this works when you run the original PostScript, but
doesn't work when you run the PDF file.

We know from the original work on this issue (see bug #689757) that the rules
Acrobat uses on whether to render a /.notdef or not are incomprehensible. In
particular we know that making a font symbolic does not force display. I
mention
this because I had thought that the fact that the font was symbolic was why
Acrobat displayed this one.

[Comment 10]
In PostScript we always render the /.notdef glyph, because that's the way the
specification is written and mostly everyone sticks to the spec. In PDF,
however, although the spec is written so that the /.notdef glyph should be
rendered, Adobe Acrobat 'sometimes' (and I haven't been able to work out a rule
for this) doesn't render the /.notdef but instead leaves a gap equivalent to
its
width.
This leads to complaints about 'hollow squares' or 'boxes'. Of course these are
technically correctly rendered, but Acrobat doesn't display them so we are seen
as incorrect.

[PDF Reference, Third Edition]
All Type 1 font programs contain an actual glyph for the character named
.notdef. The effect produced by showing the .notdef character is at the
discretion
of the font designer; in Type 1 font programs produced by Adobe, it is the same
as the space character. If an encoding maps to a character name that does not
ex-
ist in the Type 1 font program, the .notdef character is substituted.

[PDF/A-2
http://www.pdfa.org/2011/08/pdfa-%E2%80%93-a-look-at-the-technical-side/]
PDF/A-2 will also apply stricter rules for glyphs in embedded fonts. PDF/A-2
will not allow the
use of .notdef glyphs and will only permit so-called ‘empty’ glyphs for white
space.

GhostScript seems to use the Type 1 .notdef glyph. When you extract
TimeNewRomanCyr,
open it with fontforge and convert to CID using Adobe-Identity, you see that
the .notdef character
is a rectangle.

I see those possibilities:
1) Render replacement glyphs in both PDF and PS. Looks bad, but is quite
standard compliant. However, many users might complain and
   the rasterization workaround will not work.
2) Add an option to replace .notdef by a space in both PS/PDF rendering. The
rendering could match every PDF spec (normal PDF and PDF/A),
   which is important, but it is additionally possible to get an acceptable
ouput for printing.
3) Maybe even check the pdf version for normal PDF or PDF/A.

-- 
You are receiving this mail because:
You are the assignee for the bug.