Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #222 > unrolled thread

Bad glyph causes Adobe distill failure, but works in Preview

Back to article view | Back to comp.lang.postscript

Contents

  Bad glyph causes Adobe distill failure, but works in Preview jdaw1 <jdawiseman@gmail.com> - 2011-06-03 01:46 -0700
    Re: Bad glyph causes Adobe distill failure, but works in Preview jdaw1 <jdawiseman@gmail.com> - 2011-06-03 01:46 -0700
    Re: Bad glyph causes Adobe distill failure, but works in Preview ken <ken@spamcop.net> - 2011-06-03 15:28 +0100
      Re: Bad glyph causes Adobe distill failure, but works in Preview jdaw1 <jdawiseman@gmail.com> - 2011-06-03 11:45 -0700
        Re: Bad glyph causes Adobe distill failure, but works in Preview ken <ken@spamcop.net> - 2011-06-04 10:54 +0100
          Re: Bad glyph causes Adobe distill failure, but works in Preview jdaw1 <jdawiseman@gmail.com> - 2011-06-05 04:15 -0700
            Re: Bad glyph causes Adobe distill failure, but works in Preview ken <ken@spamcop.net> - 2011-06-06 07:55 +0100
              Re: Bad glyph causes Adobe distill failure, but works in Preview jdaw1 <jdawiseman@gmail.com> - 2011-06-06 14:49 -0700
                Re: Bad glyph causes Adobe distill failure, but works in Preview ken <ken@spamcop.net> - 2011-06-07 07:50 +0100
                  Re: Bad glyph causes Adobe distill failure, but works in Preview jdaw1 <jdawiseman@gmail.com> - 2011-06-07 02:00 -0700
                    Re: Bad glyph causes Adobe distill failure, but works in Preview ken <ken@spamcop.net> - 2011-06-07 10:37 +0100
                      Re: Bad glyph causes Adobe distill failure, but works in Preview jdaw1 <jdawiseman@gmail.com> - 2011-06-07 16:56 -0700

#222 — Bad glyph causes Adobe distill failure, but works in Preview

The next post contains a small test program, which is also at
http://www.jdawiseman.com/papers/bugs/20110603_bug_ACutAboveTheRest.ps

This works in Mac Preview, Version 5.0.3 (504.1) on Mac OS X 10.6.7,
producing the output
http://www.jdawiseman.com/papers/bugs/20110603_bug_ACutAboveTheRest.pdf
Note that the /alpha glyph produces a blank, about the width of a
character. So far, so good.

But if this is distilled with Adobe Distiller Professional 8.2.6
(21/01/2011), the job fails, producing the log file
http://www.jdawiseman.com/papers/bugs/20110603_bug_ACutAboveTheRest.log
> %%[ Error: PDF object referenced, never defined ]%%
> %%[ Error: undefined; OffendingCommand: distillsave; ErrorInfo: Internal Distiller Error 4]%%

So let’s remove the line
> {GlyphToTest glyphshow} stopped {( stopped!) =} if
and re-test with Adobe Distiller. That works:
http://www.jdawiseman.com/papers/bugs/20110603_bug_ACutAboveTheRest_no_glyphshow.pdf

Yikes. An error that isn't being caught by being trapped by “stopped”.
Please, how can this error be properly caught within PostScript?

[toc] | [next] | [standalone]

#223

%!

/GlyphToTest /alpha def
/ACutAboveTheRest 24 selectfont
27 750 moveto  (product = ) show product show (; version = ) show
version show
27 720 moveto
currentfont /CharStrings get GlyphToTest known 5 string cvs show
{GlyphToTest glyphshow} stopped {( stopped!) =} if
(end of test) show
showpage

[toc] | [prev] | [next] | [standalone]

#224

In article <989b39ed-2a02-4b74-b4ce-e07ec9d70920
@z13g2000yqg.googlegroups.com>, jdawiseman@gmail.com says...

> Yikes. An error that isn't being caught by being trapped by ?stopped?.
> Please, how can this error be properly caught within PostScript?

It *is* properly handled in PostScript. The mistake is in thinking that 
Adobe Acrobvat Distiller is a precisely donforming PostScript 
interpreter, it isn't.

Distiller ignores parts of the spec which it finds inconvenient, and 
often does not trap errors properly in a stopped context.

Try the same test on Ghostscript.

			Ken

[toc] | [prev] | [next] | [standalone]

#225

Perhaps bad phrasing on my part: sorry. My hand-coded PostScript uses
execform a lot. Ghostscript, in effect, ignores execform, doing a
vanilla re-execution, and so greatly enlarging the PDF. Mostly for
that reason, I want to use Adobe Distiller.

But, as you say, Adobe Distiller isn’t conforming. (And Adobe doesn’t
say to what extent this has been fixed in Acrobat X Pro — one lost
sale.) So, is there a way in PostScript to have a chance of trapping
this error?

For instance, perhaps ‘currentfont /CharStrings get GlyphToTest get’
has testable properties, some values of which must be bad?

[toc] | [prev] | [next] | [standalone]

#227

In article <1ecaa8c6-b428-4e2b-aad9-b61bf5fd7ac6
@j25g2000vbr.googlegroups.com>, jdawiseman@gmail.com says...

> But, as you say, Adobe Distiller isn?t conforming. (And Adobe doesn?t
> say to what extent this has been fixed in Acrobat X Pro ? one lost
> sale.) So, is there a way in PostScript to have a chance of trapping
> this error?

In PostScript, yes, using Distiller, no.

 
> For instance, perhaps ?currentfont /CharStrings get GlyphToTest get?
> has testable properties, some values of which must be bad?

If all you want is to know if a glyph exists in a (PostScript) font then

currentfont /CharStrings get /name known will return true if /name is a 
named entry in the CharStrings dicitonary, and false if it isn't.

Note that this will *not* work for CIDFonts, type 0 (OCF) fonts or Type 
42 fonts. You would need to do other kinds of tests on these fonts.

Using glyphshow is bad practice, its slow and can make PDF files which 
are unsearchable. You should define an Encoding array which uses the 
glyphs you need instead. Obviously its quite reasonable to test for the 
exsitence of those glyphs first :-)



			ken

[toc] | [prev] | [next] | [standalone]

#228

Thank you: much in that reply. 

-- glyphshow. If every glyph is separately re-encoded into an ASCII-97-
x61 lower-case 'a', would that really help searching and copy-pasting?
That seems very odd. 

-- Fonts. Ideally I would like the PostScript to know whether the
glyph exists, and whether its drawing code is of non-zero length, and
whether any other mandatory pieces exist and have some chance of being
well-formed. Please, if that, or parts of that, are easy and obvious
to you, and you have the inspiration (or pre-existing code), consider
adding code to the following.

% name  GlyphMightBeGoodInCurrentFont  bool
/GlyphMightBeGoodInCurrentFont
{
    0 dict begin
    /GlyphToTest exch def
    % ...
    % test what type is currentfont; 
    % get GlyphToTest's details; 
    % test for possible omissions and errors.
    end
} def  % /GlyphMightBeGoodInCurrentFont

Thank you.

[toc] | [prev] | [next] | [standalone]

#230

In article <ad4e9d97-66b9-4613-9891-
43345de2440c@h7g2000yqa.googlegroups.com>, jdawiseman@gmail.com says...

> -- glyphshow. If every glyph is separately re-encoded into an ASCII-
97-
> x61 lower-case 'a', would that really help searching and copy-pasting?
> That seems very odd. 

Not sure what you mean. I said that using glypshow instead of an 
Encoding would harm copy/paste/search, that doesn't entail putting all 
the glyphs in the same Encoding position.

 
> -- Fonts. Ideally I would like the PostScript to know whether the
> glyph exists, and whether its drawing code is of non-zero length, and
> whether any other mandatory pieces exist and have some chance of being
> well-formed. Please, if that, or parts of that, are easy and obvious
> to you, and you have the inspiration (or pre-existing code), consider
> adding code to the following.

That's a major project, and not one I would care to tackle in 
PostScript. Not least because at least some commercial fonts mark 
CharStrings dictionary as 'no access' in order to prevent people 
stealing the glyph outlines. Obviously the interpreter can still access 
the dat ain order to draw the glyph, but the PostScript language can't.

Then there's the fact that there are a lot of different types of fonts, 
with different minimum requirements.

The PostScript interpreter does all this checking so that you don't have 
to, I'd leave the job there personally.


			Ken

[toc] | [prev] | [next] | [standalone]

#239

glyphshow: if encoding, each glyph has to go somewhere. Given a glyph,
by what algorithm should an encoding number be chosen?

Fonts: But if the task is left to the interpreter, and the interpreter
is Distiller, it breaks.

What I envisage is that those with expertise might wish to add further
tests to the following. It won't be perfect, but the larger the
proportion of possible failures that it can capture, the better.
GlyphMightBeGoodInCurrentFont returns false if the glyph is known to
be bad, otherwise it returns true. So false means "definitely bad";
true means "probably good". Obviously more probably is better.

% name  GlyphMightBeGoodInCurrentFont  bool
/GlyphMightBeGoodInCurrentFont
{
	1 dict begin
	/GlyphToTest exch def
	true
	1 {
		currentfont /FontType get 1 eq
		{
			currentfont /CharStrings get /GlyphToTest known not {pop false
exit} if
		} if  % Type 1
	} repeat  % 1 {...} repeat  allows exit
	end
} bind def  % /GlyphMightBeGoodInCurrentFont

The other problem is that the few thousand fonts on my Mac OS X all
seem to be of type -1, whatever that might mean.

[toc] | [prev] | [next] | [standalone]

#240

In article <ac02462d-913c-43da-a15e-
dbc55132fc9e@j25g2000vbr.googlegroups.com>, jdawiseman@gmail.com says...
> 
> glyphshow: if encoding, each glyph has to go somewhere. Given a glyph,
> by what algorithm should an encoding number be chosen?

Is it equivalent to a regular character, eg a capital A or whatever ? If 
not (its a symbol) then the exact position is irrelevant. However its 
still worth using an Encoding (simply use the positions incrementally 
from 1) rather than glyphshow, because glyphshow usually doesn't cache 
the glyph bitmap, so its slow.

 
> Fonts: But if the task is left to the interpreter, and the interpreter
> is Distiller, it breaks.

Only if the font is broken. If the font isn't broken you catch the 
error, but then what are you going to do ? You still can't draw the 
glyph.....

 
> The other problem is that the few thousand fonts on my Mac OS X all
> seem to be of type -1, whatever that might mean.

Possibly they are TrueType fonts ? How are you determining the type ?



			Ken

[toc] | [prev] | [next] | [standalone]

#241

If I can't show the glyph, it isn't shown. That isn't a problem, as my
task is to make more robust:
www.jdawiseman.com/papers/placemat/fonts_illustrated.ps
What this does is make a document containing a one-line illustration
of each good font on the system. For fonts for which a glyph is
broken, I want to show what can be shown, and certainly not terminate
the whole job without output.

Hence each glyph-font pair is used once or perhaps twice, and so there
is no advantage to caching the glyph bitmap.

Not sure where the -1s came from. (Sorry.) My Mac has fifteen 0s,
twenty-one 1s, one hundred and eighty 2s, and two thousand four
hundred and seventy-four 42s, according to:

[
	(*) {cvn 255 string cvs} 255 string /Font resourceforall
] {{findfont /FontType get =} stopped pop} forall

[toc] | [prev] | [next] | [standalone]

#243

In article <a49fe40c-a67d-4b0b-ab3e-c8c3b6031196
@h7g2000yqa.googlegroups.com>, jdawiseman@gmail.com says...

> of each good font on the system. For fonts for which a glyph is
> broken, I want to show what can be shown, and certainly not terminate
> the whole job without output.

Well, for base fonts you'll need the Type 1 font specification, the CFF 
font specification, the TrueType font specification (for type 42 fonts) 
and you'll also want to read the sections of the PostScript Language 
Reference Manual dealing with fonts. Then you'll need the CIDFont 
specification and the CMap specification for CIDFonts. I'm assuming you 
aren't going to check type 3 fonts.

I'm also assuming that you are allowing the interpreter to instantiate 
the font, rather than checking the validity of the font file on disk 
yourself. You seem to be most interested in checking the validity of the 
glyph program rather than the font. So you can pass up a bunch of other 
checks on the presence/absence of various font elements, if they aren't 
valid the interpreter won't load the font (but it may well generate an 
error).

Type 0 = composite (probably CID but maybe OCF) fonts. Either way you'll 
need to check the type 0 font for correctness, then each of the 
descendants.  For CIDFonts with PostScript outlines you'll need to pick 
the glyphs for glyphshow using a CID rather than a glyph name, but 
that's not a problem. Enumerating the CharStrings shoul dbe adequate.

Type 1 & Type 2 are the same, in effect, CFF is just a more compact 
representation. You can simply enumerate the CharStrigns dictionary for 
both I believe. 

Type 42 fonts are TrueType fonts, so you need to extract the sfnts data, 
and then decode the various TrueType tables (checking them for 
validity), then take the GLYF table and (using the LOCA table to locate 
each glyph program) check each of the glyphs in turn. Note that you will 
need to apply the CVT and FPGM table data to each glyph, and the 
application of that data can render the glyph invalid, so essentially 
you will need a full TrueType interpreter.

For CIDFonts with TrueType outlines you will need to use the same type 
42 interpreter.


Its a lot of work, and not work that I would be keen to take on in 
PostScript personally.


			Ken

[toc] | [prev] | [next] | [standalone]

#244

Yikes! Thank you again for the lucid detail.

Maybe, and I recognise the improbability of this, maybe a passing
reader has already written much of this code for some other purpose
and would be willing to share.

Maybe.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web