PostScript - embedded font error in ghostscript

Author

embedded font error in ghostscript

news@celticbear.com

2005-11-21, 7:01 pm

We just switched servers from one with an older GS to this new one
which I installed AFPL Ghostscript 8.51 on.
GS is a fresh install, but I rsync'ed the font directories right over.
On the old server, the JPGs we'd create from PDFs were sharp and crisp,
but now they're choppy and poor quality.

I ran in shell an example of the dynamically generated GS command we
use, to see about any errors, and this is what I get:

[root@s75712 tmpuploaded]# /usr/local/bin/gs
-I/usr/share/fonts/default/Type1/ -dBATCH -sDEVICE=jpeg
-sOutputFile=./11.jpg ./1.pdf

AFPL Ghostscript 8.51 (2005-04-18)
Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
**** Warning: Fonts with Subtype = /TrueType should be embedded.
But ArialMT is not embedded.
Substituting font Helvetica for ArialMT.
Loading NimbusSanL-Regu font from
/usr/share/fonts/default/Type1/n019003l.pfb... 2566672 948562 1577248
265379 3 done.[color=darkred]

**** This file had errors that were repaired or ignored.
**** The file was produced by:
**** >>>> PDFlib 5.0.3p1 (PHP/Linux) <<<<
**** Please notify the author of the software that produced this
**** file that it does not conform to Adobe's published PDF
**** specification.

I did a search for GS and font issues, but all I'm finding are threads
of people asking similar questions and no replies that appear to work
for the poster.
And the Sourceforge forum doesn't seem to have any help on the subject.

Any suggestions would be appreciated!
-Liam

John-Paul Stewart

2005-11-21, 7:01 pm

news@celticbear.com wrote:
> We just switched servers from one with an older GS to this new one
> which I installed AFPL Ghostscript 8.51 on.
> GS is a fresh install, but I rsync'ed the font directories right over.
> On the old server, the JPGs we'd create from PDFs were sharp and crisp,
> but now they're choppy and poor quality.
>
> I ran in shell an example of the dynamically generated GS command we
> use, to see about any errors, and this is what I get:
>
> [root@s75712 tmpuploaded]# /usr/local/bin/gs
> -I/usr/share/fonts/default/Type1/ -dBATCH -sDEVICE=jpeg
> -sOutputFile=./11.jpg ./1.pdf
>
> AFPL Ghostscript 8.51 (2005-04-18)
> Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved.
> This software comes with NO WARRANTY: see the file PUBLIC for details.
> Processing pages 1 through 1.
> Page 1
> **** Warning: Fonts with Subtype = /TrueType should be embedded.
> But ArialMT is not embedded.
> Substituting font Helvetica for ArialMT.

The problem may lie with the fact that font substitution is happening.
Do you have TrueType fonts installed on your system? (Try 'locate
arial.ttf'.) If so, does Ghostscript know where to find them (in its
Fontmap)? (Use 'xfstt --gslist --sync' as root and append its output to
the appropriate Fontmap file for your version of Ghostscript.) I'm
guessing their either missing or Ghostscript can't find them, and that's
why Helvetica is being substituted. But I don't know if that alone
would cause the image degredation you're seeing.

The problem may be something else entirely, such as image resolution.
Since you're not specifying a resolution on the GS command line, if the
default has changed between the old and new versions, that could also be
part of the problem. I'd recommend adding '-r96' to make JPEGs with a
96 DPI resolution (a common value for monitors). You can go higher, of
course, but unless you're printing the resulting JPEGs you may just end
up with unnecessarily large JPEG files. I'd try playing with resolution
a bit first, before mucking about with fonts.

news@celticbear.com

2005-11-21, 9:57 pm

John-Paul Stewart wrote:
> news@celticbear.com wrote:
>
> The problem may lie with the fact that font substitution is happening.
> Do you have TrueType fonts installed on your system? (Try 'locate
> arial.ttf'.) If so, does Ghostscript know where to find them (in its
> Fontmap)? (Use 'xfstt --gslist --sync' as root and append its output to
> the appropriate Fontmap file for your version of Ghostscript.) I'm
> guessing their either missing or Ghostscript can't find them, and that's
> why Helvetica is being substituted. But I don't know if that alone
> would cause the image degredation you're seeing.
>
OK, well, "locate arial.ttf" came up with no results. So I guess TTF's
aren't installed.
I'll look into getting that done. Thanks for the tip!

> The problem may be something else entirely, such as image resolution.
> Since you're not specifying a resolution on the GS command line, if the
> default has changed between the old and new versions, that could also be
> part of the problem. I'd recommend adding '-r96' to make JPEGs with a
> 96 DPI resolution (a common value for monitors). You can go higher, of
> course, but unless you're printing the resulting JPEGs you may just end
> up with unnecessarily large JPEG files. I'd try playing with resolution
> a bit first, before mucking about with fonts.

Hmm, I tried -r96, but that expanded the image beyond the display. That
is, we have a set xy for the image, and that resolution seemed to
expand it so that only the bottom left 66% of the image was visible.
Maybe that has something to do with the mogrify we run the image
through next.
I'll look into playing with this too.

Thanks for the reply!!
Liam

François Robert

2005-11-23, 3:57 am

"news@celticbear.com" <news@celticbear.com> wrote in
news:1132627277.535849.98240@g44g2000cwa.googlegroups.com:

>
> John-Paul Stewart wrote:
....[color=darkred]
Does that affect text ? raster images ? line & curves drawing ?
[color=darkred]
....[color=darkred]
> Hmm, I tried -r96, but that expanded the image beyond the display.
> That is, we have a set xy for the image, and that resolution seemed to
> expand it so that only the bottom left 66% of the image was visible.
> Maybe that has something to do with the mogrify we run the image
> through next.
....
For the "jpeg" device, you can also specify a so called "quality level"
(command line switch -dJPEGQ=<integer> where <integer> is between 0 and
100. Default 75). That alters the "lossyness" of the JPEG compression,
not the overall number of pixels (so that should take care of say, edge
"ringing" but not of a lack resolution)
Note that browsing the "History" section of GS 8.53, I could not find an
indication that this command line setting behavior and/or default has
changed since the "jpeg" device was introduced. YMMV.

________________________________________
_______________
François Robert
(to mail me, reverse character order in reply address)

news@celticbear.com

2005-11-23, 7:00 pm

Fran=E7ois Robert wrote:
> "news@celticbear.com" <news@celticbear.com> wrote in
> news:1132627277.535849.98240@g44g2000cwa.googlegroups.com:
>
> ...
> Does that affect text ? raster images ? line & curves drawing ?

Well it appears to only be affecting the dynamically generated text.
The image itself appears to be the same.
Which reinforces the idea, it seems, that the problem is the embedded
font issue.
I'm looking into font embedding, but not having much luck.

>
> ...
> ...
> For the "jpeg" device, you can also specify a so called "quality level"
> (command line switch -dJPEGQ=3D<integer> where <integer> is between 0 and
> 100. Default 75). That alters the "lossyness" of the JPEG compression,
> not the overall number of pixels (so that should take care of say, edge
> "ringing" but not of a lack resolution)
> Note that browsing the "History" section of GS 8.53, I could not find an
> indication that this command line setting behavior and/or default has
> changed since the "jpeg" device was introduced. YMMV.
>
That's pretty

! But unfortunately, when I increase the JPG quality,
it expands the image beyond the set size, so basically while the
display is sext say 300x200, the image itself is like 600x400 and so
it's only shown the bottom left half of the larger image.
(But, that might be an issue with an unrelated problem I'm having with
-geometry in the mogrify command we use agter the gs command.
The image quality on default is OK. The problem is the horrible quality
of the remdered font. And so I'm certain now that the problem lies in
the lack of the font being embedded.

Thanks for your time and reply! I'll certainly keep the -dJPEGQ switch
in mind for other projects!
Liam

François Robert

2005-11-23, 7:00 pm

"news@celticbear.com" <news@celticbear.com> wrote in
news:1132758387.704742.123230@g14g2000cwa.googlegroups.com:

>
> François Robert wrote:
>
> Well it appears to only be affecting the dynamically generated text.
> The image itself appears to be the same.
> Which reinforces the idea, it seems, that the problem is the embedded
> font issue.
> I'm looking into font embedding, but not having much luck.
....[color=darkred]
> That's pretty

! But unfortunately, when I increase
> the JPG quality, it expands the image beyond the set size,
> so basically while the display is set say 300x200,
> the image itself is like 600x400 and so it's only shown
> the bottom left half of the larger image.

A bit of clarification is in order here :
- "pixel counts" : (how many pixels an image has, horizontally or
vertically)
- "dimensions" : how big is the image in the physical world (measured
thus in meters, inches, centimeters, feet...)
- "resolution" : pixel count / dimension
- "QFactor" (or its sibling "JPEGQ"): a number that is used in the JPEG
compression algorithm that changes the level of detail lost during
compression (but does _not_ alter the pixel count)
- "quality" : a very subjective concept, most of the time hard to
describe by words. However, most peopke recognizes visually a "bad
quality image", but it is ususally quite difficult to elicit verbally
_what_ makes it "bad". QFactor, resolution, sharpness, noise, histogram
distributions, even artistic considerations, etc... can all contribute
to "quality".

In your case, you have increased the _pixel count_ (from 300x200 to
600x400) and since there are more pixels to look at, the image
presumably has finer level of detail, hence a "better quality".

I was suggesting something different, however: For the _same_ number of
pixels, "JPEGQ" can tune the JPEG device to produce a lower or higher
number of distinct colors (That's an over-simplification, but you get
the idea). If "JPEGQ" is high, abrupt color transitions (edges) will be
kept "sharp". If "JPEGQ" is low, they will become "blurred", "smeared"
(ringing effect). Since black text on white background are made mostly
of edges, that setting may affect "quality" too. Without changing the
pixel counts.

> (But, that might be an issue with an unrelated problem I'm
> having with -geometry in the mogrify command we use agter
> the gs command.
> The image quality on default is OK. The problem is the
> horrible quality of the rendered font. And so I'm certain
> now that the problem lies in the lack of the font being
> embedded.
I kind of remembered some issues with fonts that were rasterized and
converted to Type3. I cannot find exactly the posts made at the time
though.
________________________________________
_______________
François Robert
(to mail me, reverse character order in reply address)

Sponsored Links