I've pushed the fixes fonts to:
https://github.com/ArtifexSoftware/urw-
base35-fonts/commit/c15105598aa7eb256b1ebfcecd3d078801521e73
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871377
Title:
URW
I should note, these will be the "upstream" source repositories, not the
Ubuntu ones (that will take a bit longer).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871377
Title:
URW Nimbus font issue
Super, thank you. I'll update the relevant repositories later today.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1871377
Title:
URW Nimbus font issue
To manage notifications about this bug go to:
We've had an update from URW++ and the glyph in question looks much
better to me, but not being a speaker/reader of any language(s) that use
that glyph, it would be great if the OP would be willing to check the
update before I commit and push it to our github repo (then Till can
pick it up for incl
*** This bug is a duplicate of bug 978120 ***
https://bugs.launchpad.net/bugs/978120
Hi Christian,
So, my impression, from what you've described is that this isn't the
same issue as the others in this bug (not least because the Postscript
error is different: "typecheck" rather than "invalidac
*** This bug is a duplicate of bug 1686568 ***
https://bugs.launchpad.net/bugs/1686568
** This bug has been marked a duplicate of bug 1686568
Firefox Does Not Respond. Process can not be killed. Terminal commands to
kill the process freeze. Logout Freeze.
--
You received this bug notific
It probably needs an admin - hopefully, they'll see it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1688636
Title:
Firefox gets stuck in a page fault
To manage notifications about this bug go to:
FWIW, I see the same symptoms with both Firefox and (just now)
Thunderbird, and I am using the Nouveau NVidia drivers - I mention that
as I seem to recall a vaguely similar sounding issue a couple of years
ago that could be worked around why switching away from the NVidia
proprietary drivers (which
Would it be fair to guess is this same as, or related to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1686568
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1688636
Title:
Firefox gets stu
The problem is already fixed in 9.18. If wanted to apply the fix to the 9.16
code in Ubuntu 15.10, you can pull the patch from:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=668406a5
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Your file contains neither fonts nor CIDFonts, it is simply one big
image. Whilst it is common practice for scanner produced PDF to use OCR
to overlay the scanned image with non-marking characters (obviously,
being non-marking, the actual font used does not really matter), this
file does not do so.
Bruno,
To be honest, I don't know what differs between the two tools, as they
both come from Cairo, I assumed that pdftops was just a small wrapper
around the same code as pdftocairo but with the options pre-set for PS
output.
I'm a Ghostscript developer, so I can't really answer specifics about
The problem, I suspect, is the way Cairo rights PDF files (the gmap.pdf
file you attached above was created by Cairo). The Cairo *always* writes
the page contents into one or more PDF transparency groups - even when
all the contents are really opaque.
The issue is that, due to the way PDF works (a
Two things:
1) I *really* don't understand why Ghostscript configuration file are
being installed by poppler. It would be worth finding out how (and even
if) poppler actually uses them, because I rather feel poppler and
Ghostscript configurations *should* be separate. For example, if I get
time, I
Apologies, Till, for the delayed reply - I *thought* replying on a bug
also subscribed me to it, but clearly not! (I have subscribed now).
There is a bit of guess work here, as I don't fully understand the file
locations.
We are mainly concerned with the cidfmap file. Now, there is a set of
cidfm
The root problem here is that the Ubuntu package contains cidfmap
mappings that provide substitutions for various CIDFonts that may not be
embedded in incoming files. But the Ghostscript package does not depend
on the package(s) containing those font files, so those font files are
often not availab
Sorry, but that "printout" file is still the Poppler created one.
I'm afraid I'm going to need Till's input on this as my knowledge of
cups is limited (and now exhausted) - I only really do the Ghostscript
end of things..
--
You received this bug notification because you are a member of Ubun
Odd, that "printout" file is from the cairo/poppler "pdftops" filter,
rather than the Ghostscript one that I deal with.
If you can repeat the tests after running:
lpadmin -p HP-Color-LaserJet-2550 -o pdftops-renderer-default=gs
And post your results and another "printout" file. If you want to, yo
As the file you have is PDF, you should be trying:
lpr -P -o psdebug .pdf
or
lp -d -o psdebug .pdf
If that works, let us know.
If not, you need to follow the instructions starting here:
https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_printer
And then
Tomas,
Thanks for taking the time to report it to the manufacturer (not many
users do!).
If I'm honest, I doubt you'll get much response (based on past
experience), but as I said before, I think we need to start making it
clear to printer makers that these broken implementations aren't
acceptable
Okay, so it's clear that the Toshiba has an issue with how we handle
TrueType/Type42 fonts - I know I'm repeating myself, but the Postscript
is *totally* correct, many other interpreters from many source handle it
happily, and both myself and another engineer with a great deal of
Postscript experie
So, it is *definitely* to do with how ps2write emits Type42/TrueType
fonts - that's a pain. As I said before, what ps2write does is slightly
ls odd for this, but it *totally* standard Postscript.
Anyway, can you try this one, too, please? Depending on the result of
this, I can make a recommendatio
Tomas,
Can you give this one a try, and tell us how it behaves, please?
Thanks
** Attachment added: "Uncompressed file with no ttf font"
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/978120/+attachment/4043114/+files/printout_testpage_noncompressed_chris_nottf_20140325.ps
--
Hrm, that's not a surprise, but it is a pain. I need to give this some
thought.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/978120
Title:
Toshiba Estudio 230 printer driver bug
To manage noti
Tomas, can you try this one, too, please - same procedure.
FWIW, I'm expecting this to fail in the same way as the previous one.
** Attachment added: "Cut down file"
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/978120/+attachment/4040998/+files/printout_testpage_really_noncomp
OKay, I have "manually" decompressed the various parts of the contents
of the file (you'll note it is now double the size!). If you could
follow the procedure to send this file directly to the printer (-oraw)
and let me know the result. Thanks.
Note that, once again, five different Postscript int
Hmm, that's not producing a non-compressed file - hopefully, Till will
pipe up to tell us what's going wrong (as mentioned elsewhere, I'm not a
CUPS guy, I'm a Ghostscript guy.).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
Okay. so the next thing I'll ask you to do is to try step 10 from this section:
http://tinyurl.com/p5cb4kf
And see if that works better, and if not, attach the non-compressed
file.
Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Yes, that's probably the "subset prefix" - it's six random letters that
differentiate a complete font from a subset font.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/998087
Title:
printer ERROR:
Tomas,
if you're getting the same "invalidfont" error as reported in #978120,
then we can continue with that bug, if your error is different, I'd
prefer a new bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
Tomas,
As this bug was reported as a problem with a HP LaserJet 4050, for which
a fix has been released, I would ask you, please, to open a new bug, and
subscribe me (cliddell) to the new bug, and we'll work forward from
there.
The instructions of what to do are here:
https://wiki.ubunt
Sorry, I haven't spoken, read or written German since I was at school!
But Google translate did a good enough job to get the idea of what they
said and, frankly, I strongly disagree with what they say.
What they have written implies that they have not actually analysed the
Postscript you have sent
If I am correct, and (like the cases we've hacked around with the Ghostscript
output) the Postscript is perfectly valid and correct,
you may find that the Opera developers aren't willing to change that perfectly
valid Postscript output to work around a bug in a printer.
Really this is very like
PDFs are vector format (with the option embed raster graphics "images"
in them) so they don't have an inherent resolution.
It's more likely that a "light" PDF doesn't have images, or other
"advanced" PDF features, that need converted into something else (PDF
supports features that Postscript does
Oh, and no need to apologize - we all want to get this stuff working.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/998087
Title:
printer ERROR: invalidaccess OFFENDING COMMAND: filter
To manage
Till, you know I can't answer that. For the issues we're looked at *not
one* has actually highlighted any issue with Ghostscript's Postscript
output, the Postscript has *always* been valid and correct.
There's simply no way I can guess at what bugs other interpreters may or
may not have.
--
You
I'm confused: my understanding was that this bug was resolved.
Besides, the thread seems to have become rather convoluted and confused.
If a problem is still occurring, could you open a new bug (subscribe me
so I see it), and we'll take things from there, please?
--
You received this bug notifi
Again, that all points to the bug being in the printer. The fact you can
convert the PS to PDF is a strong indication that the PS is correct (as
per the PS specification).
Don't forget that both PDF and PS are vector formats, so have nearly
infinite variations in how to produce (near) identical ou
Okay, that's what we need to see, thanks.
However, that Postscript comes from Opera, not from Ghostscript, so I'm
not really the upstream contact.
As far as I can tell, that's valid Postscript, so the problem is a bug
in the printer - it should really be reported to Kyocera.
--
You received thi
Sorry, but the file attached above (GoogleMapsPrintout.ps) appears to be
a direct export from Opera (the metadata has: "%%Creator: Opera"),
rather than the Postscript captured as detailed here:
https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_printer
--
Yo
Frank,
We've made changes to address problems with Konica-Minolta printers, but
you may have found another problem.
We know how to track these problems down, but they take a lot of time
and effort (and paper!) on the part of the users as well as us, and so
far, no one has seemed willing to see th
I should add that the previous bug was with without "UseCIEColor"
pdfwrite could not access/create device independent colours, hence was
emitting a PDF with device dependent colours despite the
"UseDeviceIndependentColor" setting.
The reason UseCIEColor has to be set explicitly, and can't be done
That is the correct behaviour. Previous versions ignored the error, and
produced the incorrect output.
This is not a bug..
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1218350
Title:
stackunde
The file you attached in comment #71 definitely comes from Ghostscript (the
meta-data comments at the head of the file show that), and not from poppler, so
that was the configuration that gave you the error in 12.10.
If you grab the attachment from #71, decompress/untar it, then do:
lpr -P -or
Laurent,
Could you post the error message you get from that file, please? I'm a
bit confused because the file you posted in comment #71 seems different
to the ones I remember looking at before in this bug - it's *much*
simpler, which is good, but I need to be sure where I should look before
I star
Thanks. Hmm, the "psdebug" option is not working as I understood it - I
*thought* it was supposed to produce very "plain" uncompressed, and (as
far as possible) "unfiltered" output. But what you've got out of it is
exactly the same as the non-psdebug output.
Till, can you confirm (or deny) what ps
On the BizHub unit referenced in the above Ghostscript bug,
investigation by KonicaMinolta UK suggested that this was a firmware bug
which has been addressed in the most recent revisions - I've yet to
receive confirmation from the user on that, but KM were unable to
reproduce the crash on their own
Could you repeat the "capture the data going to the printer" stage after
applying the "psdebug" setting to the "testing" print queue (that is,
the new print you created to send the printer data to a file), and
attach the output here, please?
Could also confirm which version of Ghostscript is insta
Jeremy,
If you don't mind, could you do me favour, and repeat the test print
after doing:
lpadmin -p test -o psdebug=true
(assuming you called your file output queue "test" as suggested in
"Getting the data which would go to the printer"), please?
It's just it will save time if I don't have to
Jeremy,
Your next step should be to try doing:
lpadmin -p -o psdebug=true
where "" is the name of the Xerox print queue, and try printing
normally.
If that still gives the error on the printer, refer to:
https://wiki.ubuntu.com/DebuggingPrintingProblems#Getting_the_data_which_would_go_to_the_
Jeremy,
Whilst we will investigate this, we are confident that the Postscript
being emitted by Ghostscript is valid and correct, based on our own
inspection of the Postscript code, and since it works correctly on a
large number of devices.
Given that, it seems almost certain that there is a bug i
Till,
I believe we've been through enough of these that you should know the
basic groundwork required before I can really do anything.
To start with, try the "uncompressed" CUPS option, and if that doesn't
work, then gather the (preferably uncompressed) Postscript that is being
sent to the printe
Sorry, I know I'm repeating myself, but I'm *not* a CUPS developer (I
work on Ghostscript), so I don't know the ins and outs of getting the
data out of CUPS.
Hopefully, Till will pipe up...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Once again, that is a PDF from the CUPS print queue, not the Postscript
that is actually being sent to the printer.
Note you are not supposed to be using the *default* configuration, you
have to apply the settings from Till in post #57.
--
You received this bug notification because you are a mem
Laurent,
If you follow Till's instructions above, and do:
lpadmin -p printer -R pdftops-renderer-default
lpadmin -p printer -o psdebug-default=true
Then do whatever you did in post #43 to capture the data being sent to
the printer, and then post it here again.
Then I can check the result is what
Jacques,
Sorry, but I don't see anywhere above that you confirmed that the test I asked
for in post #44 worked for you. In fact, you said (post #51):
'So I do not need to do "lpr -P -oraw ko-nodebug-cut001.ps",
since there is no problem'
To me, that sounds like you didn't use lpr, but some oth
Opening the file in Document Viewer and printing it from there is
completely useless in context because it just goes through the CUPS
filters, which I specifically said we needed to avoid for this test.
Your original problem, as reported, came about as a result of changing
the CUPS Postscript gene
So, how are you printing the PS file in post #44 if not with the lpr
command?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/978120
Title:
Toshiba Estudio 230 printer driver bug
To manage notificati
> Does this info help to narrow down the problem ?
No, it does not.
If you run the test I posted in comment #44 and report the results, that
*would* help narrow down the problem.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:
Realy?!?!? I did *not* expect that.
That suggests that there is a bug either with the LZW decode filter, or
with that filter's interaction with other aspects of the interpreter. I
have seen such things before.
Thanks for testing it Marty.
Okay, so if I can ask as many interested parties from
Huh, debug option doesn't do everything I thought it did - never mind, that
gave me enough I could get what I need with a little manual hacking.
First of all, your printer is broken!!! Four different Postscript
interpreters, all from different vendors (include Adobe) all agree that
this is valid,
Laurent.
I'm afraid that
"https://wiki.ubuntu.com/DebuggingPrintingProblems#Capturing_print_job_data";
is wrong, or at least misleading these days.
What it captures is the file(s) from the cups print queue, which is
printer independent (PDF, as a matter of fact), and not the final page
descriptio
Laurent,
1 - Erm, dunno! As I said, I just copied the instruction from a comment
from Till on another bug. I don't know the best way to find which PPD
your printer is actually using, but the PPD name *usually* reflects the
make/model of the printer - for example, mine is "HP-
Officejet-h470.ppd".
Aha, assuming nothing has changed, grabbing the printer PS can be done
like this (originally from Till):
cupsctl FileDevice=yes
lpadmin -p test -E -v file:/tmp/printout /etc/cups/ppd/.ppd
Now print the job which failed on the printer "test" and as soon as the
job disappears from the queue attach
What normally happens is that someone posts the Postscript that is sent
to the printer from the Ghostscript workflow, preferably uncompressed by
using the "psdebug=true" option. Ideally, in cases like this, also from
the Postscript from the Poppler workflow.
We then go through a process where I cu
Jacques,
Did the:
lpadmin -p -o psdebug=true
have any effect?
Also, can you try a different font from Ubuntu-Medium? Myabe one of the
DejaVu ones if you have them.
If we have to really debug this, it will take quite a bit of effort from
both us (and possible a fair amount of paper!).
Chris
-
dac922, Did you (or could you) try the:
lpadmin -p -o pdftops-renderer-default=gs
lpadmin -p -o psdebug
As I understand it, the "psdebug" option disables a bunch of compression
stuff in the Ghostscript output. It seems lots of printers have really
bad decompression implementations :-(
Thanks,
It seems that the fix for this was:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8031fd57
For me (using git cherry-pick) the patch applies cleanly to the 9.05
sources.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
No, we're not going to add that option to ps2write, that would, frankly,
defeat the whole point of ps2write.
There is already a cups imagetops filter, so it would be a lot less work
to have the option have Ghostscript convert to pnm and then do imagetops
on the pnm.
--
You received this bug noti
Well, I think it's fair to say that if Kyocera's very own driver does
not/cannot produce PS that the printer can interpret, it's not
unreasonable that we don't. I'm not saying if there were a reasonable
way for us to workaround the problem that we wouldn't, on that basis -
but frankly, none of us c
I've attached the result of printing the first page from Acrobat,
through the KPDL Windows driver. It looks similar to the poppler output
(it builds the clipping path using charpath operations).
The Kyocera driver does, indeed, include a "Print As Image" option - although
it comes out grayscale,
I can't see any way to reproduce the page description accurately without
running into the same problem.
IIRC, some Windows Postscript drivers have the option to produce the
page as an image, which I believe is intended to work around this type
of issue. Thus reducing the PDL complexity, for such l
Frankly, that's what I feared. The Adobe produced Postscript can be made
to resemble either the Ghostscript output or the poppler output
(depending on the settings used in Acrobat), and it looks to me as
though this is simply a case where the (mostly minor) differences in the
imaging capabilities o
Okay, so we think we know the source of the problem.
All the text in the PDF is drawn with text rendering mode 7, which means
"add to clip". So drawing the text accumulates an enormous path, which
is then use to clip. Hence the limitcheck error on clip.
Now the Ghostscript ps2write output (for so
I'll need the exact Postscript being sent to the printer, and the
command line invoking Ghostscript to create the PS.
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1049635
Title:
Cannot print
I'm relieved to put another issue to bed!
BIG thanks to Felix for his patience (and paper!) in helping us track
this down.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1026974
Title:
Printing Bahn
Right, again with much help from Felix, we're narrowed the problem down
to the fact that the images in the originating PDF request
interpolation, thus so does Ghostscript's Postscript output, and it
seems that, for the class of image in question, at least, the 1350D's
implementation of interpolatio
For tracking the Ghostscript end of this, see:
http://bugs.ghostscript.com/show_bug.cgi?id=693197
** Bug watch added: Ghostscript (AFPL) Bugzilla #693197
http://bugs.ghostscript.com/show_bug.cgi?id=693197
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
Felix joined us on #ghostscript and with his help, I narrowed the
problem down to the fonts in the file.
The way ps2write currently works is that it writes a pfb (binary encoded
Type 1 Postscript font) and ASCII85 encodes it so the binary data
doesn't trip up the communications channels.
The Kyoc
Again, I really didn't expect that :-(
http://www.ghostscript.com/~chrisl/printout-004.ps
That one should (on a fully functional printer) produce no output at all
- not even a blank page.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Hmm, I did *not* expect that :-(
If you can try this one:
http://www.ghostscript.com/~chrisl/printout-003.ps
In this one I have removed all the ps2write "marking content", and
replaced it with just a blank page.
If IRC would be easier, I'm on #ghostscript on freenode most days (I'm
on UK time) -
Felix,
by the way, if there is a more convenient way of communicating for you
than using launchpad (e-mail or IRC or something) then let me know. I
can summarise progress on the problem here as required.
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Okay, so it is not a problem with the LZW filter. That still leaves
another (non-compressing) filter that could be at fault, but I'll try to
narrow things down a bit before we get to that. On that basis, I'll work
on modifying the version with the compression, since it's a lot smaller
(obviously!).
Darn it! Sorry, I forgot I needed to add the device specific stuff to
the file.
http://www.ghostscript.com/~chrisl/nolzw2.ps
Should be more what we want apologies again.
Chris
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
Felix,
First of all, (and I may have told you this before, but I would like it
recorded in this, and all relevant bugs): this is *not* a bug with the
Ghostscript Postscript output. The GS Postscript is valid - we spent a
lot of time confirming that when these bugs started to come to light.
The fau
Felix,
that's the poppler emitted PS (which is useful, I would probably have
asked for it down the line anyway), but I really need the PS generated
by Ghostscript, if you could thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
I'll need the Postscript that gets sent to the printer, too.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1025061
Title:
Kyocera FS-1300DN cannot print with gs backend
To manage notifications abou
Oh, it looks like this is one of the printers we opted to disable page
"stream" compression, but IIRC, Till, you put in user controls to allow
disabling of font compression - that might be a good place to start.
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
I can't find a gs command line anywhere in the logs. Could someone post
the command line cups gives to GS these days? Perhaps that could be
added to the cups logging? Also any PS that gets prepended.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subsc
Steve,
Thanks for trying that, it's eliminated the compression filters as being
the problem.
Before I resort to "instrumenting" the Postscript, which will use up
paper, can you try this file, please?
Again, like this:
lpr -P -o raw stream1-uc2.ps
This changes the how the font data is encoded (
Steve,
Could I ask you to send this file (stream1-uc.ps) to your printer,
please? It is the same content as your original, but with the
compression removed.
You need to use:
lpr -P -o raw stream1-uc.ps
If the HP in question is your only only, or your CUPS default printer,
you can probably leav
Steve,
Till is looking into the possibility of providing an option to use the
poppler tool as a workaround, I'll leave it to him to update on that
when/if he has news.
Obviously, in the long term, we'd like to resolve these issues that
various printers have with the Postscript output from Ghostsc
Steve,
Yes, Ghostscript has replaced poppler, mainly due to the color
management now available in GS, which currently only applies to printer
drivers which use raster output - rather than ones like yours that use
Postscript. Ultimately, the improved color management will apply to
Postscript (and P
I can't answer that.
I can say that Ghostscript's ps2write output is valid Level 2 Postscript
- in other words, it is compliant with the language defined in the Adobe
Postscript Language Reference Manual Edition 2. And not especially
challenging Postscript, either.
Let me ask this: if gcc fails t
Not being over sensitive, but:
"What is discussed here is the broken postscript code that makes Brother
printers to fail completely."
The Postscript is *not* broken, it is demonstrably valid. But it hits a
breakage in the Brother printer - the problem is with the printer, not
the Postscript.
Chr
Till,
AIUI,
lpr -o raw ...
Is just a passthrough direct to the printer, so I *still* have to
manually edit *every* test file to get it to work on the printer.
If it's the pdftops filter that adds (at least some of) the printer
specific stuff, then I'll assume there's no way for me to avoid the h
What we were talking about is, if you look in Acrobat Pro, in the dialogue for
creating Postscript, it has a drop down menu titled "Transparency Flattener
Preset" which has the options "High Resolution", "Medium Resoluiton" and "Low
Resolution". Those options are totally independent of the resol
Till,
Sorry, that's not quite what I meant by "inject Postscript". What I was
hoping for was a way to bypass the PDF print queue (PDF is *so*
unsuitable for that!), so that an end user can take Postscript directly
out of Ghostscript and push it into the CUPS "back end" to have the PPD
derived stuf
Felix,
The main thing is, I need the PS that actually gets sent to the printer
so that I can get the device specific settings that are inserted by CUPS
(and are not present in the "bare" Ghostscript output). Then I can
create variants of the PS from Ghostscript, and "hand patch" the
Postscript to
As there is no transparency, no shaded fills and no CIDFonts in this
file, there is nothing which is really affected by changing the
resolution for ps2write.
Given the error observed above, I would guess this is another filter
problem.
If Felix can attach the PS from Till's test PDF, I can take a
1 - 100 of 155 matches
Mail list logo
