fit-page equivalent for postscript

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.

cups-pdf problem

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?

At 15:59 25/04/2013 -0400, Alex Korobkin wrote:

>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?

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 

What is incorrect in this piece of PostScript code?

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

What's up with basic rasterization?

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?

--

-- 
David Kastrup

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

CID fonts in 9.07?

This seems weird enough that I allow it may be me, but....

Having successfully used 8.53, I'm trying to build 9.07.  It generally 
works well, and the graphics rendering quality is dramatically improved, 
but I'm encountering this issue with CID fonts.

It makes no difference what configure options I use EXCEPT cidfont.dev:

1. Without cidfont.dev, selecting a CID font results in "ioerror" when 
gs tries to read the CID font file.

2. With cidfont.dev, loading the CID feature set results in an error of 
some kind while reading gs_cidtt.ps.  (It just says something about 
/undefined in .uninstallpagedevice, IIRC.)  This file is now located in 
/usr/share/ghostscript/9.07/Resource/Init, but was in 8.53/Resource/lib.

Has something changed that I'm not dealing with, or is there an issue?  
I notice that cidfont.dev does not appear in the Makefile unless I put 
it there.

I've switched back to 8.53.  I can rebuild/re-install either/both 
configurations of 9.07 and supply more complete/detailed information if 
you need it.

Thanks.

Windows printing from standard input as System user

I seem to be experiencing permission issues when I use the dash (-) 
option, which is to read from standard input for gsprint.  I'm hoping 
there is a way to resolve this issue?

It comes up in MS WIndows when gsprint is called from an application run 
by System ( for me, it's the Tomcat web app).  The printing with gsprint 
won't work unless i'm running the application not as System, but with an 
explicit user with an account.  I suspect it's because gsprint takes the 
standard input and writes to a temp file, and System didn't have 
privilege to do that.  Unfortunately, running the application as a 
specific user isn't desirable in this case, and we want to run it as 
System.

Does anyone have any suggestion how I can resolve this issue? Thanks in 
advance for any help!

-Al

MuPDF 1.2 - saving forms

> Message: 1
> Date: Sat, 09 Mar 2013 22:39:49 -0600
> From: "John A. Wallace" <jw72253 <at> verizon.net>
> To: <gs-devel <at> ghostscript.com>
> Subject: [gs-devel] MuPDF 1.2
> Message-ID: <000001ce1d49$4cba9f00$e62fdd00$ <at> net>
> Content-Type: text/plain; charset="us-ascii"
> 
> I just installed the new version 1.2 of MuPDF on my 64-bit Win7 and all
> appears to be working well. That is wonderful. I do have a question
> about the new feature for filling in forms.  What is the point of being
> able to fill in a form in MuPDF if I cannot also print or save the
> document?  What am I missing?

Okay, well I just made a faux pas (open mouth and insert foot)! It does save
PDF forms with text entered. However, the error was not entirely my fault
because there is no "Save" button or menu option for doing so. It does not
look like it would save based on what I can see and what I expect. I found
that it saved only by accident as I was closing the program. When data has
been entered in a form's text field, upon closing the form it prompts to
save it. So now we have a fully functional MuPDF with form saving ability.
That is definitely great news. Thanks for the support of Windows users too.

MuPDF 1.2

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

"Pure" GPL Ghostscript Build?

I noticed that the jpegxr library included in the GPL Ghostscript source
is not GPL compatible.  It also only seems to be necessary for  XPS
files and I am just interested in ps to pdf capability.  So does it make
sense to build a version without jpegxr?  Is there a way to compile
without jpegxr?  Thanks!

Neil

Re: How to prevent interpolating artefacts when drawing transformed PDF

On 17.02.2013 at 02:53 Robin Watts wrote:

>> See here for a screenshot that shows what it looks like:

>> http://www.falkenhahn.com/tmp/mupdf_artefacts.png

> Right, except how is the background red?

The red background color serves just as an illustration for any arbitrary background
color or pattern.

>> Is there any way to get rid of these artefacts? I would like to have pixmap that I can draw
>> to any arbitrary background (e.g. red, green, yellow colored...) but I do not know the color
>> of the background at the time of calling fz_run_page(). Thus, I somehow need to prevent MuPDF
>> from interpolating pixels by blending with the current pixmap background color.

> Right, so you want to start with every pixel being blank and transparent.

>   [0] = 0
>   [1] = 0
>   [2] = 0
>   [3] = 0

> Then what you are left with is a pixmap where the edge pixels are not 
> blended with anything - when you plot it, *you* must do the blending.

Yes, that's exactly what I want to do! But the problem when working with a 0-prefilled
pixmap is that mupdf does *not* draw the white page background of the PDF file. It just
draws the actual objects like text, images... but it doesn't draw the background. It simply
draws on top of the background that is in the passed pixmap. Have a look at this picture:

http://www.falkenhahn.com/tmp/mupdf_bgfill.png

The upper part of the page should appear in white color. But here it appears in red because
I use a 0-prefill. If I want this area to appear in white, then I have to do a 0xff prefill
but then I face the problem that there are white artefacts at the edge pixels and I cannot
smoothly draw the page to backgrounds other than white. 

Is there a way around this? The only thing that comes to my mind is to hack mupdf to
draw a white rectangle having the size of the entire page as the very first thing for
every page. But that's surely not a very nice solution :/

Tks

Andreas