<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel">
    <title>gmane.comp.printing.ghostscript.devel</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3806"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3805"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3804"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3803"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3802"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3801"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3800"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3799"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3798"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3797"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3796"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3795"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3794"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3793"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3792"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3791"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3790"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3789"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3788"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3787"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3806">
    <title>fit-page equivalent for postscript</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3806</link>
    <description>&lt;pre&gt;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.
&lt;/pre&gt;</description>
    <dc:creator>Lee Howard</dc:creator>
    <dc:date>2013-05-15T19:51:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3805">
    <title>Re: cups-pdf problem</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3805</link>
    <description>&lt;pre&gt;

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&amp;lt; at &amp;gt;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:

       &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; "AMH" == Amani M Hamdan  writes:
&lt;/pre&gt;</description>
    <dc:creator>Amani M. Hamdan</dc:creator>
    <dc:date>2013-05-07T11:41:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3804">
    <title>Re: cups-pdf problem</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3804</link>
    <description>&lt;pre&gt;
AMH&amp;gt; I found that CUPS 1.5 embedes DejaVuSans_00 and DejaVuSansMono_00
AMH&amp;gt; to the PDF while CUPS 1.4 embedes DejaVuSans and DejaVuSansMono; Do
AMH&amp;gt; you have any idea if I can change the default font of texttops? and
AMH&amp;gt; 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
&lt;/pre&gt;</description>
    <dc:creator>James Cloos</dc:creator>
    <dc:date>2013-05-06T18:08:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3803">
    <title>Re: cups-pdf problem</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3803</link>
    <description>&lt;pre&gt;

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&amp;lt; at &amp;gt;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:

       &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; "AMH" == Amani M Hamdan  writes:

AMH&amp;gt;  I would like to inquiry about an issue, I googled about it but didn't
AMH&amp;gt; reach solution; I am using Ubuntu 12.04, CUPS 1.5.3 and Ghostscript
AMH&amp;gt; 9.05, also I am using cups-pdf (virtual PDF printer). My problem is
AMH&amp;gt; when printing te&lt;/pre&gt;</description>
    <dc:creator>Amani M. Hamdan</dc:creator>
    <dc:date>2013-05-06T08:54:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3802">
    <title>Re: cups-pdf problem</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3802</link>
    <description>&lt;pre&gt;
AMH&amp;gt;  I would like to inquiry about an issue, I googled about it but didn't
AMH&amp;gt; reach solution; I am using Ubuntu 12.04, CUPS 1.5.3 and Ghostscript
AMH&amp;gt; 9.05, also I am using cups-pdf (virtual PDF printer). My problem is
AMH&amp;gt; when printing text file, the generated PDF has embeded fonts without
AMH&amp;gt; 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 se&lt;/pre&gt;</description>
    <dc:creator>James Cloos</dc:creator>
    <dc:date>2013-05-05T19:52:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3801">
    <title>cups-pdf problem</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3801</link>
    <description>&lt;pre&gt;

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&amp;lt; at &amp;gt;e-receipt.us.com
Website : www.e-retailgreen.com
Tel : +962 79 052 4264

_______________________________________________
gs-devel mailing list
gs-devel&amp;lt; at &amp;gt;ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel&lt;/pre&gt;</description>
    <dc:creator>Amani M. Hamdan</dc:creator>
    <dc:date>2013-05-05T12:03:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3800">
    <title>Re: What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3800</link>
    <description>&lt;pre&gt;
CL&amp;gt; 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
&lt;/pre&gt;</description>
    <dc:creator>James Cloos</dc:creator>
    <dc:date>2013-04-25T23:35:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3799">
    <title>Re: What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3799</link>
    <description>&lt;pre&gt;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 &amp;lt;cloos&amp;lt; at &amp;gt;jhcloos.com&amp;gt;

_______________________________________________
gs-devel mailing list
gs-devel&amp;lt; at &amp;gt;ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel&lt;/pre&gt;</description>
    <dc:creator>Alex Korobkin</dc:creator>
    <dc:date>2013-04-25T23:32:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3798">
    <title>Re: What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3798</link>
    <description>&lt;pre&gt;
AK&amp;gt; Encouraged by your hints I've been able to re-create the problem with a
AK&amp;gt; non-confidential document. The original PDF and PostScript files are
AK&amp;gt; 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 dep&lt;/pre&gt;</description>
    <dc:creator>James Cloos</dc:creator>
    <dc:date>2013-04-25T22:15:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3797">
    <title>Re: What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3797</link>
    <description>&lt;pre&gt;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 &amp;lt;cloos&amp;lt; at &amp;gt;jhcloos.com&amp;gt;

_______________________________________________
gs-devel mailing list
gs-devel&amp;lt; at &amp;gt;ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel&lt;/pre&gt;</description>
    <dc:creator>Alex Korobkin</dc:creator>
    <dc:date>2013-04-25T21:33:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3796">
    <title>Re: What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3796</link>
    <description>&lt;pre&gt;

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

chris
_______________________________________________
gs-devel mailing list
gs-devel&amp;lt; at &amp;gt;ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel&lt;/pre&gt;</description>
    <dc:creator>Chris Liddell</dc:creator>
    <dc:date>2013-04-25T21:24:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3795">
    <title>Re: What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3795</link>
    <description>&lt;pre&gt;
AK&amp;gt;   0 0 Td
AK&amp;gt;   [1 0 0 -1 139 18] Tm
AK&amp;gt;   0 0 Td
AK&amp;gt; &amp;gt; /F12_0 13.3333 Tf
AK&amp;gt; &amp;gt; (\012\355)
AK&amp;gt; &amp;gt; [13.3333
AK&amp;gt; &amp;gt; 0] Tj
AK&amp;gt; &amp;gt; [1 0 0 1 0 0] Tm
AK&amp;gt; &amp;gt; 0 0 Td
AK&amp;gt; &amp;gt; [1 0 0 -1 139 18] Tm
AK&amp;gt; &amp;gt; 0 0 Td
AK&amp;gt;   /F11_0 13.3333 Tf
AK&amp;gt;   (\000\003)
AK&amp;gt;   [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
&lt;/pre&gt;</description>
    <dc:creator>James Cloos</dc:creator>
    <dc:date>2013-04-25T21:09:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3794">
    <title>Re: What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3794</link>
    <description>&lt;pre&gt;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 &amp;lt;ken.sharp&amp;lt; at &amp;gt;artifex.com&amp;gt;

_______________________________________________
gs-devel mailing list
gs-devel&amp;lt; at &amp;gt;ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel&lt;/pre&gt;</description>
    <dc:creator>Alex Korobkin</dc:creator>
    <dc:date>2013-04-25T21:10:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3793">
    <title>Re: What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3793</link>
    <description>&lt;pre&gt;


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). F&lt;/pre&gt;</description>
    <dc:creator>Ken Sharp</dc:creator>
    <dc:date>2013-04-25T21:08:03</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3792">
    <title>What is incorrect in this piece of PostScript code?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3792</link>
    <description>&lt;pre&gt;Hi all,

While working with a PostScript document that cannot be interpreted by
GhostScript, I found out that removing this (marked with &amp;gt;) 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--   %&lt;/pre&gt;</description>
    <dc:creator>Alex Korobkin</dc:creator>
    <dc:date>2013-04-25T19:59:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3791">
    <title>Re: What's up with basic rasterization?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3791</link>
    <description>&lt;pre&gt;

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
&lt;/pre&gt;</description>
    <dc:creator>Ken Sharp</dc:creator>
    <dc:date>2013-04-18T13:36:33</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3790">
    <title>What's up with basic rasterization?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3790</link>
    <description>&lt;pre&gt;
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
st&lt;/pre&gt;</description>
    <dc:creator>David Kastrup</dc:creator>
    <dc:date>2013-04-18T13:07:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3789">
    <title>Re: CID fonts in 9.07?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3789</link>
    <description>&lt;pre&gt;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.
&lt;/pre&gt;</description>
    <dc:creator>Jim Howard</dc:creator>
    <dc:date>2013-04-17T18:03:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3788">
    <title>Re: CID fonts in 9.07?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3788</link>
    <description>&lt;pre&gt;
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 &amp;lt;GenericResourceDir&amp;gt;/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 &amp;lt;jiho&amp;lt; at &amp;gt;finestplanet.com&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Chris Liddell</dc:creator>
    <dc:date>2013-04-17T07:39:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3787">
    <title>Re: CID fonts in 9.07?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3787</link>
    <description>&lt;pre&gt;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.
&lt;/pre&gt;</description>
    <dc:creator>Jim Howard</dc:creator>
    <dc:date>2013-04-16T18:32:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3786">
    <title>Re: CID fonts in 9.07?</title>
    <link>http://permalink.gmane.org/gmane.comp.printing.ghostscript.devel/3786</link>
    <description>&lt;pre&gt;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.
&lt;/pre&gt;</description>
    <dc:creator>Jim Howard</dc:creator>
    <dc:date>2013-04-16T17:00:15</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.printing.ghostscript.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.printing.ghostscript.devel</link>
  </textinput>
</rdf:RDF>
