Ken Sharp | 22 Jun 10:33 2015

Re: Fwd: Interactive postscript from HP printer...

At 09:24 22/06/2015 +0100, Ken Sharp wrote:

>This maybe a little off topic from Ghostscript development per se

It is off-topic, yes, I'd suggest you try Stack Overflow instead for a 
wider range of respondents.

>The printer understands postscript but I'd like to look at the stack and 
>debug interactively. It seems like the interactivity (echo and executive 
>output to stdio) is turned off.
>When I connect with a terminal window to the printer I get no echo and no 
>output (in response to a pstack command for example).
>Are there some PS commands I need to execute to see the executive stdio or 
>is this a PJL command ?

In general you cannot reliably go interactive with a printer, many 
implementations simply don't allow it (bear in mind that early PostScript 
printers used a uni-directional parallel printer interface). While it is 
possible with some printers I can attest from painful personal experience 
that in general you get nothing back from a printer.

So most likely you cannot do what you want with the HP printer, if it can 
be done, only the manufacturer can tell you how.

Your best bet is to use Ghostscript to develop the PostScript and send it 
to the printer for verification as required.

If that's not good enough then you will probably  have to resort to 
actually printing stuff out on paper.

(Continue reading)

Michael K | 21 Jun 20:39 2015
Picon

Interactive postscript from HP printer...

This maybe a little off topic from Ghostscript development per se but I need to test some postscript code directly on an HP printer. Your indulgence is requested!
The printer understands postscript but I'd like to look at the stack and debug interactively. It seems like the interactivity (echo and executive output to stdio) is turned off.
When I connect with a terminal window to the printer I get no echo and no output (in response to a pstack command for example).
Are there some PS commands I need to execute to see the executive stdio or is this a PJL command ?

thanks,
  Michael



_______________________________________________
gs-devel mailing list
gs-devel <at> ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel
Ken Sharp | 16 Jun 18:07 2015

Re: Glyph Outlines in Trace Driver

At 15:51 16/06/2015 +0000, Allen Blaylock wrote:
> >The SVG output device was never completed, and didn't work well. In
> >particular text didn't work well (though this is more to do with the
> >limitations of SVG in this area), so the device was dropped.
>
>Would you recommend that I don't use the SVG driver as an example/starting 
>place then?

Entirely up to you, the only thing I would note is that the SVG device is 
deprecated and no longer shipped.

>  I was thinking of using the trace driver as a starting place initially. 
> I also see that MuPDF an SVG device of sorts which might provide another 
> good template.

Depends if you want to handle PostScript or just PDF.

                 Ken
Allen Blaylock | 16 Jun 17:51 2015

Re: Glyph Outlines in Trace Driver

>The SVG output device was never completed, and didn't work well. In 
>particular text didn't work well (though this is more to do with the 
>limitations of SVG in this area), so the device was dropped.

Would you recommend that I don't use the SVG driver as an example/starting place then? I was thinking of
using the trace driver as a starting place initially. I also see that MuPDF an SVG device of sorts which
might provide another good template.

Allen Blaylock
Ken Sharp | 13 Jun 09:29 2015

Re: Glyph Outlines in Trace Driver

At 22:15 12/06/2015 +0000, Allen Blaylock wrote:

>How do I determine which transforms I need to apply?

All of them :-)

>Where are they stored (I know where ctm is and how to access it)?

The font matrix is stored in the font instance. For a regular font that and 
the CTM are the only matrices you need to worry about. The 'original' font 
matrix scales the co-ordinates in the font into the canonical 1x1 
PostScript unit space. The scaled font matrix is that matrix scaled by the 
argument applied to scalefont. Which is why you need the matrix from the 
specific font instance, to get the correct scaling.

For CIDFonts its more complex, you need to apply one or both of the parent 
and descendant font matrices (As I recall there must be at least one, but 
may not be both). The 'next' and 'prev' members are not the descendants, 
they point to the next font in the font cache.

In ghostpdl/gs/devices/vector/gdevpdtc.c the routine 
process_composite_text() demonstrates one part of this:

             font_code = pte->orig_font->procs.next_char_glyph
                 ((gs_text_enum_t *)&curr, &chr, &glyph);
             /*
              * We check for a font change by comparing the current
              * font, rather than testing the return code, because
              * it makes the control structure a little simpler.
              */
             switch (font_code) {
             case 0:     /* no font change */
             case 1:     /* font change */
....
                 new_font = curr.fstack.items[curr.fstack.depth].font;
....
             case 2:     /* end of string */
                 break;
             default:    /* error */
                 return font_code;
             }
             break;

>able to find a good description of them in the code or the documents online.

You will need the Type 1 font specification (aka 'Black and white' book), 
and the supplement, Adobe tech note 5015. The TrueType font specification, 
and the Type 42 description (I think that's in the 2nd edition PLRM,but 
Adobe Tech note 5012 is the stand-alone). The CFF font format 
specification, Adobe tech note 5176, you probably don't need to worry about 
the type 2 CharString format but its tech note 5177. Tech note 5092 for an 
overview of CIDKeyed fonts and Tech Note 5014 for CIDFonts and CMaps

I can't recall where the wrinkles about type 0 fonts and their descendants 
and how to apply their matrices is given. I do remember it took a lot of 
finding and careful reading and rereading of the specification to get it 
all working correctly.

>Is there a set of code which sets everything up to append the path to the 
>path provided in text_begin?

No, Ghostscript doesn't render text by appending the outline to the path 
(except for very large glyphs). The glyph is rendered and the bitmap added 
to the glyph cache, the bitmap is then rendered at the correct position 
given by the current point, and the current point is advanced by the glyph 
metrics (taking overrides into account). Subsequent uses of that glyph are 
then rendered from the glyph cache in the same way.

>The end goal is to just grab the text outline and dump it like any other 
>paths in the trace driver, I may be chasing the wrong solution entirely. 
>Feel free to say that as well.

Why not simply decode the font ? Its probably quicker and you get all the 
hinting information, which will already have been applied by the time you 
get a path back.

Perhaps if you said why you wanted to do this we could suggest a different 
approach. Fonts and text are in many ways the most complex area of 
PostScript, and the most convoluted and difficult to understand parts of 
Ghostscript.

                     Ken
Ken Sharp | 12 Jun 22:01 2015

Re: Glyph Outlines in Trace Driver

At 17:24 12/06/2015 +0000, Allen Blaylock wrote:

>approximately the same value. The next time text_begin is called a similar 
>move to is executed the passed in path variable is approximately the same 
>while the first element of the path returned by glyph_outline is (5927 
>1.05166e+006 moveto) with all subsequent path elements having points of 
>approximately the same value.
>
>Why is there such a large difference in the magnitudes of the path values 
>between glyph outlines?

I'd have to see your code to see what you are doing, but I suspect the 
simple answer is that you shouldn't be doing it in text_begin.

You should be appending each glyph in the enumerator's 'text_process' 
method I think.

>How would one transform the glyph outlines into the current coordinate space?

You need to apply the matrix from the font instance (bearing in mind that 
it may be a descendant font of a CIDFont or type 0 PostScript composite 
font, so you may have to apply either/both of the parent and descendant 
matrices) and the Current Transformation Matrix (ctm), which is stored in 
the graphics state.

>Is text_begin the correct place to be doing this kind of operation?

I suspect not, but its kind of hard to be sure without seeing and tracing 
your code. Also I'm working from memory at this time of night which is not 
completely reliable....

                     Ken
Allen Blaylock | 12 Jun 19:24 2015

Glyph Outlines in Trace Driver

Hello,

The text_begin function has a gx_path which the documentation notes to define the path where the character
outline is to be appended. I have the trace driver print that value out, and then call glyph_outline on the
font. I also have the font stroked which presumably dumps out something similar if not the same as the glyph
outline. The text is has the operation TEXT_FROM_STRING so there may be multiple glyphs being processed
during each text processing operation. 

As an example first time the text_begin function is called the path variable passed in contains (6.62891
82.3711 moveto) and the first element of the path returned by glyph_outline is (204 -256 moveto) with all
subsequent path elements having points of approximately the same value. The next time text_begin is
called a similar move to is executed the passed in path variable is approximately the same while the first
element of the path returned by glyph_outline is (5927 1.05166e+006 moveto) with all subsequent path
elements having points of approximately the same value.

Why is there such a large difference in the magnitudes of the path values between glyph outlines? 
How would one transform the glyph outlines into the current coordinate space?
Is text_begin the correct place to be doing this kind of operation?

A full output of the trace output can be found here: 
http://pastebin.com/y5UXCEWQ
And the input file:
http://filebin.ca/250Fnqs1hm3a/Untitled-7.pdf
Ken Sharp | 22 May 19:00 2015

Re: Fwd: Odd form of comment: "%Begin Resource"

At 17:56 22/05/2015 +0100, Ken Sharp wrote:

>I have been using [%%Creator: GPL Ghostscript GIT PRERELEASE 908 (ps2write)]

Try using a more recent version of Ghostscript.

                 Ken
Mike Breeden | 22 May 17:12 2015
Picon

Odd form of comment: "%Begin Resource"

I have been using [%%Creator: GPL Ghostscript GIT PRERELEASE 908 (ps2write)] 
to process PDF files to PostScript. Sometimes viewing them in GhostView, I get a warning dialog box:

------------------------------------------------------
Document Structuring Conventions

DSC Warning at line 3613:
%EndProlog

%%BeginResource: /%%EndResource 

The number of Begin and End comments do not match
-------------------------------------------------------

Sure enough, looking in the PostScript file with a text editor shows that sometimes there is a tag "%BeginResource" with only a single leading '%' sign instead of the usual two '%' characters. It seems to happen only in tags like:
-------------------------------------------------------
%BeginResource: file (PDF FontFile obj_30)
30 0 obj
<</Filter[/ASCII85Decode
/LZWDecode]
/Length1 33844/Length 38146>>stream
-------------------------------------------------------
That type of code block seems always to preceed a large block of characters that probably is actually a character representation of hex data.

The "%%EndResource" tag always has both leading '%' characters.

If I select "Ok" at the warning in GhostView, I will see the page displayed correctly. Also, the file prints correctly.
The first question is why would this happen? Why the missing '%'?
If I then manually go in and insert the (5 out of 30 tags) missing '%' characters, GhostView will open the document without any warnings. I can live with that. I wrote some code to automatically correct the document by converting "%BeginResource" to "%%BeginResource". The documents print fine.
 
Now how we process documents for printing is to concatenate a bunch of files together (maybe 20 Meg) and send them to the printer as a single job. 
If I do that with the corrected files, I get an error after or during the printing of the second corrected document. It does not happen with uncorrected documents. Before stopping, the printer does print a message:
-------------------------------------------------------
ERROR:
undefined
OFFENDING COMMAND:
am
Stack:
--nostringval--
5
-------------------------------------------------------

Does anyone have any idea what that means?

Thank you, Michael

_______________________________________________
gs-devel mailing list
gs-devel <at> ghostscript.com
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel
Paolo Bolzoni | 14 May 05:29 2015
Picon

Anonymize a pdf

Dear list,

Some conferences want anonymous paper.

Using LaTeX hyperref package it is easy to remove some metadata, like:
Title, Subject, Author... but in the .pdf stays an annoying metadata
called "PTEX.Fullbanner." Besides the fonts names are still visible.

So my question is, using gs it is possible to print a .pdf into
another .pdf so that:
- all not strictly necessary metadata is removed
- the fonts names are replaces with gibberish

About the last point, all the fonts are embedded subfonts, so the name
is not important.

Your faithfully,
Paolo
Ken Sharp | 27 Apr 12:34 2015

Re: Using gs it is possible to scale a PDF printing it larger

At 18:27 27/04/2015 +0900, Paolo Bolzoni wrote:

>It is possible to scale as losslessy as possible (overall in term of
>vectors) a pdf from a4 to a0?

Very well phrased question :-)

Yes, set the media size to the desired size, set -dFIXEDMEDIA to prevent 
the input PDF resetting it, and set -dPDFFitPage to have the PDF scaled to 
fit the page.

If you use the pdfwrite device the result will be (as lossless as currently 
possible) a new PDF file scaled to the desired size.

Certain aspects of the new PDF file may not reflect the original, some 
metadata is not carried forwards, images may be recompressed in the same 
format (beware of JPEG images in the input, specify Flate compression for 
colour images if this is likely), there may be some other things I haven't 
thought of.

                     Ken

Gmane