gmane.comp.printing.ghostscript.devel

fit-page equivalent for postscript

Lee Howard — 2013-05-15T19:51:14

Hello,

I'm using -dPDFFitPage successfully when processing PDFs.  What is the 
equivalent for when processing postscript documents? -dEPSFitPage does 
not seem to work.

I'm using Ghostscript 9.07.

Thanks,

Lee.

Re: cups-pdf problem

Amani M. Hamdan — 2013-05-07T11:41:06


After doing multiple tries, I found the following results
1. texttops filter is not used , only pdftopdf, pdftops and pstops are used. 
2. If the generated PDF doesn't have unicode, it may be selectable but 
you cannot search or copy text from it. 
3. you can use pdffonts command to check if the PDF file contains 
unicode or not. 
4. If I print test page (from cups administration utility) using the 
same printer, the PDF file will be encoded. 

I attached for you the following :
* sample of corrupted PDF (Receipt_Page.pdf)
* the used text file to print PDF(Receipt Page.txt)
* printed test page (Test_Page.pdf)
* CUPS error log when printing receipt page (error_log(for receipt page))
* CUPS error log when printing test page (error_log(for test page))

Best Regards ... 

Amani M. Hamdan
Java Developer
retailGreen, Inc. 
E-Mail : amanih< at >e-receipt.us.com
Website : www.e-retailgreen.com
Tel : +962 79 052 4264

On Mon, 06 May 2013 14:08:22 -0400, James Cloos  wrote:

       >>>>> "AMH" == Amani M Hamdan  writes:

AMH> I found that CUPS 1.5 embedes DejaVuSans_00 and DejaVuSansMono_00
AMH> to the PDF while CUPS 1.4 embedes DejaVuSans and DejaVuSansMono; Do
AMH> you have any idea if I can change the default font of texttops? and
AMH> why CUPS 1.5 appends "_00" to the font name?

Interesting.  Upstream cups and my install of 1.5.4 use a font cups calls
Monospace which, as I wrote, is based on DejaVuSansMono.  (Perhaps only
renamed.)

And text selection (at least for ascii) works here.  The font is subset
and includes a /CharSet entry in the /FontDescriptor object which
provides names for the glyphs.  That /CharSet is what allows text
selection to work. 

I wonder whether your distribution uses something other than upstream
textotps?

Can you provide an example pdf?

-JimC

Re: cups-pdf problem

James Cloos — 2013-05-06T18:08:22

AMH> I found that CUPS 1.5 embedes DejaVuSans_00 and DejaVuSansMono_00
AMH> to the PDF while CUPS 1.4 embedes DejaVuSans and DejaVuSansMono; Do
AMH> you have any idea if I can change the default font of texttops? and
AMH> why CUPS 1.5 appends "_00" to the font name?

Interesting.  Upstream cups and my install of 1.5.4 use a font cups calls
Monospace which, as I wrote, is based on DejaVuSansMono.  (Perhaps only
renamed.)

And text selection (at least for ascii) works here.  The font is subset
and includes a /CharSet entry in the /FontDescriptor object which
provides names for the glyphs.  That /CharSet is what allows text
selection to work.

I wonder whether your distribution uses something other than upstream
textotps?

Can you provide an example pdf?

-JimC

Re: cups-pdf problem

Amani M. Hamdan — 2013-05-06T08:54:23


Thanks James for giving me clear explanation about "how CUPS, cups-pdf 
and ghostscript work". 
In fact, I need to work with virtual PDF printer other than using 
convertor program, because I need to catch print jobs before sending 
them to the actual printer. 
I found that CUPS 1.5 embedes DejaVuSans_00 and DejaVuSansMono_00 to 
the PDF while CUPS 1.4 embedes DejaVuSans and DejaVuSansMono; Do you 
have any idea if I can change the default font of texttops? and why 
CUPS 1.5 appends "_00" to the font name?

Best Regards ... 

Amani M. Hamdan
Java Developer
retailGreen, Inc. 
E-Mail : amanih< at >e-receipt.us.com
Website : www.e-retailgreen.com
Tel : +962 79 052 4264

On Sun, 05 May 2013 15:52:17 -0400, James Cloos  wrote:

       >>>>> "AMH" == Amani M Hamdan  writes:

AMH>  I would like to inquiry about an issue, I googled about it but didn't
AMH> reach solution; I am using Ubuntu 12.04, CUPS 1.5.3 and Ghostscript
AMH> 9.05, also I am using cups-pdf (virtual PDF printer). My problem is
AMH> when printing text file, the generated PDF has embeded fonts without
AMH> encoding, therefore cannot select, search or copy from the created file. 

What is happening here is:

he submits a plain text file to cups
cups' texttops filter converts that to postscript
cups-pdf uses ghostscript's pdfwriter to convert that ps to pdf

the resulting pdf lacks toUnicode or other means a viewer could
use to do text extraction. 

Cups 1.5 comes with a ttf font set based on DejaVu Sans Mono which its
texttops filter uses by default.  The goal of that filter is to create
postscript to pass directly to postscript printers, which probably is
why it doesn't try to ensure text extraction of its output can work. 

It would be helpful to see the postscript document which gets sent to
cups-pdf to confirm my hypothesis. 

If you can find a program which directly converts plain text to pdf, it
should work better than using cups-pdf. 

-JimC

Re: cups-pdf problem

James Cloos — 2013-05-05T19:52:17

AMH>  I would like to inquiry about an issue, I googled about it but didn't
AMH> reach solution; I am using Ubuntu 12.04, CUPS 1.5.3 and Ghostscript
AMH> 9.05, also I am using cups-pdf (virtual PDF printer). My problem is
AMH> when printing text file, the generated PDF has embeded fonts without
AMH> encoding, therefore cannot select, search or copy from the created file. 

What is happening here is:

     he submits a plain text file to cups
     cups' texttops filter converts that to postscript
     cups-pdf uses ghostscript's pdfwriter to convert that ps to pdf

     the resulting pdf lacks toUnicode or other means a viewer could
      use to do text extraction.

Cups 1.5 comes with a ttf font set based on DejaVu Sans Mono which its
texttops filter uses by default.  The goal of that filter is to create
postscript to pass directly to postscript printers, which probably is
why it doesn't try to ensure text extraction of its output can work.

It would be helpful to see the postscript document which gets sent to
cups-pdf to confirm my hypothesis.

If you can find a program which directly converts plain text to pdf, it
should work better than using cups-pdf.

-JimC

cups-pdf problem

Amani M. Hamdan — 2013-05-05T12:03:05


Hello All,

 I would like to inquiry about an issue, I googled about it but didn't reach solution; I am using Ubuntu 12.04, CUPS 1.5.3 and Ghostscript 9.05, also I am using cups-pdf (virtual PDF printer). My problem is when printing text file, the generated PDF has embeded fonts without encoding, therefore cannot select, search or copy from the created file. 

While I have another machine, Ubuntu 10.10, CUPS 1.4.4 and Ghostscript 8.71, cups-pdf prints PDF files with encoded text. 
  
 I tried multiple suggestions of old posts with no benefit, like below 
  
 http://www.qc4blog.com/?p=770

Best Regards ... 

Amani M. Hamdan
Java Developer
retailGreen, Inc. 
E-Mail : amanih< at >e-receipt.us.com
Website : www.e-retailgreen.com
Tel : +962 79 052 4264

_______________________________________________
gs-devel mailing list
gs-devel< at >ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel

Re: What is incorrect in this piece of PostScript code?

James Cloos — 2013-04-25T23:35:28

CL> IIRC, that should cause a .notdef to be rendered, not a rangecheck error.

As it turned out, the rangecheck is from showing (\012\355) with
an /FMapType 2 composite font with only a single sub font.

It seems to be a bug in pdftops's conversion from CID to type0.

-JimC

Re: What is incorrect in this piece of PostScript code?

Alex Korobkin — 2013-04-25T23:32:16

Thanks a lot, I would never be able to perform such a deep analysis myself.

I will definitely report the problem to poppler team and will see what can
be done with regards to PDF generator.


2013/4/25 James Cloos <cloos< at >jhcloos.com>

_______________________________________________
gs-devel mailing list
gs-devel< at >ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel

Re: What is incorrect in this piece of PostScript code?

James Cloos — 2013-04-25T22:15:37

AK> Encouraged by your hints I've been able to re-create the problem with a
AK> non-confidential document. The original PDF and PostScript files are
AK> enclosed here.

Using poppler git master as of a couple of days ago, I get the same
error from the pdftops-generated ps if I use -level2, but it works fine
if I use pdftops -level3.

The -level1 output also fails.

The primary difference is in how the CID fonts are encoded into postscript.
Postscript3 has direct support for CID fonts; for level1 or level2 pdftops
has to translate the fonts into type0 composite fonts with type42 subfonts.

For GS at least, level3 is fine in general.

I think the bug is in poppler's pdftops -level2 output.

After defining the type42 font /DejaVuSans_00, the ps code then does this:

16 dict begin
/FontName /DejaVuSans def
/FontType 0 def
/FontMatrix [1 0 0 1 0 0] def
/FMapType 2 def
/Encoding [
0
] def
/FDepVector [
/DejaVuSans_00 findfont
] def
FontName currentdict end definefont pop

As you can see, the font has a single dependent font, and it has map
type 2.  Map type 2 means the () string passed to show has a font number
and a character number.  So the string (\012\355) means sub-font 10
character 247.

Hense the rangecheck.

If you look at the strings passed to F6_0 (arial), they look like (\0005).
Which at least looks like 16bit values rather than 8bit.

If I'm right, changing (\012\355) to (\000\0355) would fix it, but might
not print the correct glyph.

In the PDF, all of the falls to F0 (arial) are of the form:

/F0 13.3333 Tf
1 0 0 -1 10 18 Tm
<0035> Tj

but the calls to F1 (deja) look like:

/F1 13.3333 Tf
1 0 0 -1 139 18 Tm
<0AED> Tj

So pdftops is copying the <0AED> literally to (\012\355), but not
embedding enough subfonts.  The other fonts coincedentally all use
glyphs in <0000>--<00FF> and miss the bug.

You may want to report this to:

  https://bugs.freedesktop.org/enter_bug.cgi?product=poppler

As a side note, were your pdf-generator to subset the fonts, you should
avoid this bug.

-JimC

Re: What is incorrect in this piece of PostScript code?

Alex Korobkin — 2013-04-25T21:33:09

You guys are amazing. Yes, removing only this part also works.


The original PDF file was created by an in-house PDF application and
converted to PS by poppler-utils.

Encouraged by your hints I've been able to re-create the problem with a
non-confidential document. The original PDF and PostScript files are
enclosed here.


2013/4/25 James Cloos <cloos< at >jhcloos.com>

_______________________________________________
gs-devel mailing list
gs-devel< at >ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel

Re: What is incorrect in this piece of PostScript code?

Chris Liddell — 2013-04-25T21:24:02


IIRC, that should cause a .notdef to be rendered, not a rangecheck error.

chris
_______________________________________________
gs-devel mailing list
gs-devel< at >ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel

Re: What is incorrect in this piece of PostScript code?

James Cloos — 2013-04-25T21:09:54

AK>   0 0 Td
AK>   [1 0 0 -1 139 18] Tm
AK>   0 0 Td
AK> > /F12_0 13.3333 Tf
AK> > (\012\355)
AK> > [13.3333
AK> > 0] Tj
AK> > [1 0 0 1 0 0] Tm
AK> > 0 0 Td
AK> > [1 0 0 -1 139 18] Tm
AK> > 0 0 Td
AK>   /F11_0 13.3333 Tf
AK>   (\000\003)
AK>   [3.704417

The commented lines starting wit the first Tm line I beleive are part of
the next block.  The Tm Td Tm Td sequence before the offending Tf should
then be part of the block you want to elide.

Does it work if you only skip:


and leave the rest intact?

Does gs render the original pdf file correctly?  (Or was this created by
something like cairo's postscript device?)

The rangecheck in xyshow complains about:

 (\012\355) [13.3333 0] Tj

Does the embedded subset font have 0355 entries in its encoding array?
(0355 octal == 0xED hex == 237 decimal).

That seems like the most likely source of the rangecheck.

-JimC

Re: What is incorrect in this piece of PostScript code?

Alex Korobkin — 2013-04-25T21:10:25

Thanks a lot Ken, and Chris who replied privately.
That's exactly what I needed to know and your help is much appreciated.


2013/4/25 Ken Sharp <ken.sharp< at >artifex.com>

_______________________________________________
gs-devel mailing list
gs-devel< at >ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel

Re: What is incorrect in this piece of PostScript code?

Ken Sharp — 2013-04-25T21:08:03



PostScript is a programming language, and the section you have highlighted 
does not contain standard PostScript operators, therefore it must have 
defined procedures with those names.

There is no way to debug that from just a fragment, we would need to see 
the whole program.

Note that, from what you have posted here, this is PDF syntax, not 
PostScript. My guess is that the original is a PDF file, and the 
application has defined PostScript routines to execute the PDF fragments in 
PostScript terms.

If this were a real PDF file I would point out that this:

(\012\355)
[13.3333
  0] Tj

is not valid PDF syntax. Possibly you have started from a broken PDF file 
which your PDF consumer silently fixes, but which isn't going to work when 
exported to a PostScript program which expects working syntax from the PDF.

The [13.3333 0] isn't valid here, if you remove just that it might work. 
Its not uncommon for PDF consumers to ignore such syntax errors.



Well you can try using the current release (9.07). Failing that, there is 
nothing we can do in the absence of a specimen file. You could try remaking 
the file with the confidential information removed, or altered and see if 
it still fails.


             Ken

What is incorrect in this piece of PostScript code?

Alex Korobkin — 2013-04-25T19:59:57

Hi all,

While working with a PostScript document that cannot be interpreted by
GhostScript, I found out that removing this (marked with >) piece of code
makes GS happy. However, I cannot figure out what is wrong in this stance
of code.

Perhaps someone with PostScript knowledge could tell why would GS complain
about this section?

  0 0 Td
  [1 0 0 -1 139 18] Tm
  0 0 Td
  /F11_0 13.3333 Tf
  (\000\003)
  [3.704417

F12_0 represents embedded DejaVuSans font. The actual error message of GS
in debug mode:

...
resmp FindResource beg F12_0
resmp FindResource end
Error: /rangecheck in --xyshow--
Operand stack:
   139.0   18.0   (\n\355)   --nostringval--   (\n\355)   --nostringval--
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--
--nostringval--   false   1   %stopped_push   1862   1   3   %oparray_pop
1861   1   3   %oparray_pop   1845   1   3   %oparray_pop   1739   1   3
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2
--nostringval--   --nostringval--   --nostringval--   2   %stopped_push
--nostringval--   --nostringval--
Dictionary stack:
   --dict:1158/1684(ro)(G)--   --dict:1/20(G)--   --dict:85/200(L)--
--dict:74/75(L)--   --dict:19/25(L)--   --dict:0/15(L)--   --dict:0/15(L)--
  --dict:10/15(L)--
Current allocation mode is local
Last OS error: Resource temporarily unavailable
Current file position is 345679
GPL Ghostscript 9.06: Unrecoverable error, exit code 1

Sorry, cannot attach the whole file, it has confidential info in it.
Thanks in advance!

Re: What's up with basic rasterization?

Ken Sharp — 2013-04-18T13:36:33


I've seen the bug, but I've been busy. I spent the last week implementing 
high level pattern support in the PXL interpreter, evaluating what 
Distiller does with non-integer downscaling ratios answering a number of 
questions from our customers, and looking into some problems uncovered with 
valgrind and fuzzing tools.

When I have some spare time I will look at the bug in detail, until then 
there really isn't anything for me to say, I need to investigate you report 
thoroughly before I feel confident in giving you an answer.



Well you say :

"Conclusion?  Ghostscript significantly changes the available information
when converting from PostScript to PDF."

Yes, the languages are not identical, the imaging model isn't identical 
(very similar but...), so yes sometimes things are converted differently.


I will look at your problem, in the meantime please be patient, we have 
other calls on our time and reports from our paying customers are dealt 
with first.



                 Ken

What's up with basic rasterization?

David Kastrup — 2013-04-18T13:07:38

Hi, to get a hang of what settings to use for gs rendering and ps2pdf
(which is the way in which LilyPond, a note typesetter, produces PDF
from PostScript), I wrote the following short test file.

100 100 translate
matrix currentmatrix
currentstrokeadjust dup ==
2 setlinewidth 1 setlinejoin 4 { 0 0 20 30 rectstroke 30 5 translate } repeat
false setstrokeadjust
4 { 0 0 20 30 rectstroke 30 5 translate } repeat 
true setstrokeadjust
4 { 0 0 20 30 rectstroke 30 5 translate } repeat
2 copy
setstrokeadjust
setmatrix
0 100 dtransform round idtransform translate
4 { 0 0 moveto 20 0 lineto 20 30 lineto 0 30 lineto closepath
stroke 30 5 translate } repeat
false setstrokeadjust
4 { 0 0 moveto 20 0 lineto 20 30 lineto 0 30 lineto closepath
stroke 30 5 translate } repeat
true setstrokeadjust
4 { 0 0 moveto 20 0 lineto 20 30 lineto 0 30 lineto closepath
stroke 30 5 translate } repeat
setstrokeadjust
setmatrix
0 200 dtransform round idtransform translate
4 { 0 0 moveto 20 0 lineto 20 30 lineto 0 30 lineto closepath
strokepath fill newpath 30 5 translate } repeat
false setstrokeadjust
4 { 0 0 moveto 20 0 lineto 20 30 lineto 0 30 lineto closepath
strokepath fill newpath 30 5 translate } repeat
true setstrokeadjust
4 { 0 0 moveto 20 0 lineto 20 30 lineto 0 30 lineto closepath
strokepath fill newpath 30 5 translate } repeat
showpage

To not repeat myself, I quote from what I wrote about various runs of
this code with Ghostscript 9.07 on
<URL:http://code.google.com/p/lilypond/issues/detail?id=2658#c44>.

Bad news.  I've tried some experiments to see how ps2pdf would transfer
setstrokeadjust to PDF and how it affects typesetting.  Attaching the
experimental file I worked with.  From left to right, there are four
staggered boxes each drawn with a) default style of strokeadjust
(printed to terminal, too) b) strokeadjust set to true c) strokeadjust
set to false.  Four staggered boxes why?  To get different vertical and
horizontal offsets.

There are three vertical systems.  The bottom uses rectstroke, the
middle one uses the equivalent discrete strokes, the top system uses the
equivalent discrete strokes, but with strokepath fill newpath instead of
stroke.

Called with
gs -dGraphicsAlphaBits=1 test.ps
we get the straight black and white rendition.  As expected, the default
of strokeadjust (left and right) looks best.  Without antialiasing, the
strokepath+fill combination is perfectly equivalent to stroke according
to the PostScript specification.

Except that it isn't.  There are bumps at some corners in the
strokeadjusted rectangles.

Now lets start antialiasing, first with -dGraphicsAlphaBits=2 and see
where we get.

The lower two lines look pretty much indiscriminately bad now, with
stroke adjustment not helping noticeably.  The top row (using filled
paths) retains its corner bumps with strokeadjustment but gets the
thickness nicest.

Taking the default of -dGraphicsAlphaBits=4, we arrive at the version
more or less corresponding with the proposed defaults.  The "stroke
adjusted" rectangles in the lower rows have been considerably _fattened_
contrasted with the not-strokeadjusted ones and are at best a tiny bit
more consistent in thickness.  The top row looks pretty unimpressed in
the strokeadjusted versions (including corner bumps, but those are
smoothed to some less obvious gray level), but get irregularly thick in
the non-strokeadjusted version in the middle.

[...]

Now is that the end of it?  We run ps2pdf on the file (which duly
outputs "false", telling us that the default of strokeadjustment
accessible during conversion, whatever it may be worth, is off).

There is some positioning magic in the file intended to make all
vertical starting positions be different by whole pixel numbers to make
rows comparable.  This magic is resolution-dependent and does not
transfer to the PDF, so rendering differences in the two lower rows are
expected regarded the vertical positioning.

However, the results can be called nothing but appalling.  When calling
gs -dGraphicsAlphaBits=1 test.pdf
on the resulting file, the lower row looks unilaterally reasonable
independent of the strokeadjust setting.  The middle row (drawn with the
presumably equivalent strokes) has several uneven strokes in the left 8
squares drawn without strokeadjustment.  It would appear that rectstroke
_always_ uses strokeadjustment here regardless of the setting, while the
explicit strokes obey the setting.  Top row is consistently irregular.

Now what with
gs -dGraphicsAlphaBits=4 test.pdf ?

Bottom row fuzzy and consistently too thick.  Middle row partly fuzzy,
with the right strokeadjusted squares being consistently fuzzy and too
thick, and the non-strokeadjustes squares having several unexpectedly
sharp borders.  The top row is slightly sharper, with not much of a
noticeable difference between stroke adjustment (maybe a tiny bit
sharper/lighter) and not.

Conclusion?  Ghostscript significantly changes the available information
when converting from PostScript to PDF.  And even before converting to
PDF, its rasterization does not conform to PostScript rendering
specifications which require strokepath fill newpath to be equivalent to
stroke.  Not even if we switch off antialiasing and stroke adjustment.

Where does that leave us?  No really good idea.  For direct
rasterization, I like the strokepath/fill solution with antialiasing
best, but for best print results, strokeadjustment should likely be left
at its default of "off".  That drawing a rectangular path using
rectstroke gives different (and apparently automatically
stroke-adjusted) results when converted to PDF from stroking a
rectangular closed path is a catastrophic failure.  I have no good
proposal how to work around this.

End of quoted material

One conclusion is that we need to stop using ps2pdf altogether and have
to write our own PDF files if we care about quality.  We need to shut
out Ghostscript from as much of our production processes as possible
since people will judge the results based on the PDF, and the PDF
"downstream" from GhostScript has already suffered a significant
degradation of quality.  Producing our bitmap files currently uses
Ghostscript as renderer.  The version actually being used is not under
our control when considering distributions for GNU/Linux and similar.
One can improve quality quite a bit when ps2pdf is not involved and one
can play with rendering parameters.  Given the overall bugginess of the
rasterization process, I am skeptical that we'll find a set of settings
that will work over a reasonable range of Ghostscript versions.

I've already reported a bug with strokeadjustment last week to the bug
tracker.  There has not been any reply so far.

What parts of the big picture am I missing?

Re: CID fonts in 9.07?

Jim Howard — 2013-04-17T18:03:23

To finally put a wrap on this little drawn-out drama, I have now 
isolated the problem that was keeping 9.07 from getting through 
initialization.

It's dpsnext.dev in FEATURE_DEVS in the top Makefile.  When I leave this 
out, initialization never makes it to ttfont.dev, apparently.

This makes exactly 29210 bytes difference in the size of a 5 MB 
executable, so it's not like it's a big thing, but it is kind of curious.

Anyway, everything is sorted out now and I have my trimmed-down gs 9.07 
installed and working very well at this point.

Re: CID fonts in 9.07?

Chris Liddell — 2013-04-17T07:39:18

Hi Jim,

I'm glad you got there in the end - sorry I didn't get time to give you
some proper hints.

FWIW, Ghostscript will automagically derive the resource search path if
you include a "-I" option with "Resource" in it. So, for your example
you mentioned where your resource were in:
/usr/share/ghostscript/9.07/Resource

if you added:
-I/usr/share/ghostscript/9.07/Resource/Init

then the GenericResourceDir would be automatically set to:
/usr/share/ghostscript/9.07/Resource

However, it does sound like there may be a problem since we should
find an appropriately named CIDFont file (the file name should match
the CIDFont name) stored in <GenericResourceDir>/CIDFont

I'll try to look into that before the next release, but I won't get to
it for a while (mainly because you have a workable solution at the
moment).

Chris


On Tue, 16 Apr 2013 11:32:50 -0700
Jim Howard <jiho< at >finestplanet.com> wrote:

Re: CID fonts in 9.07?

Jim Howard — 2013-04-16T18:32:50

Ok, maybe.  I relied on comments in cidfmap itself, and missed Format 3 
under Explicit CIDFont Substitiution in the HTML documentation.  
Together with the -I commandline switch, this finally turned the trick, 
and I now have CID fonts in 9.07.

Sorry about the mini-flurry of confused mail.

Now I just have to find the missing piece required for initialization.

Re: CID fonts in 9.07?

Jim Howard — 2013-04-16T17:00:15

Ok, maybe not.  At least, not according to the documentation, so I 
haven't tried that approach since it isn't clear how you would.  It just 
says you have to put them in /Resource/CIDFont, like always, because 
they aren't found in the normal font search path.  The rest is about 
aliasing.

Right now I'm still running COMPILE_INITS=1, the default.  This build 
will ONLY look for CID font files in %rom%Resource/CIDFont, it will not 
look in /usr/share/ghostscript/9.07/Resource/CIDFont no matter what I 
tell it.  This despite the fact that it only wants to look for the CID 
file as a result of finding the stub file in 
/usr/share/ghostscript/9.07/Resource/Font.  And as far as I can see 
there is no way to tell it anything about the CID file, because CID 
fonts are outside the normal font search path, and nothing you tell it 
about initialization files or font files has any effect, and those are 
the only files you can tell it anything about.

My next move on this front will be to build with COMPILE_INITS=0.