Re: [poppler] Removing 0. from the version number
Perhaps it could be 1.00? On Wed, Oct 30, 2019 at 5:18 PM Albert Astals Cid wrote: > At some point in the not so far future we will end up in a version number > 0.99 and next would be 0.100 ? > > I'm suggesting we just drop the 0. for the next release and just call it > poppler-83.0.tar.xz > > Opinions? > > Cheers, > Albert > > > ___ > poppler mailing list > poppler@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/poppler -- -Alex ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] PDF form
There are special forms that Okular and Evince can't open, like this one https://www.canada.ca/content/dam/ircc/migration/ircc/english/pdf/kits/forms/imm5257e.pdf On Thu, Jul 4, 2019 at 7:03 AM Tobias Deiminger wrote: > Hi Valerio, > > Am 04.07.2019 12:05 schrieb Valerio Messina: > > I cannot find a Linux application to fill PDF forms. > > On Linux, last Acrobat is 9 and it can't too. > > Seems Evince and Okular cannot too. > > > > Does poppler support them, and someone can suggest and application > > poppler based that can fill forms? > > yes, poppler and Okular do support filling PDF forms. > I'm not sure about Evince, that should be answered by > our Gnome people here. > > What you describe smells like either a broken document > (because you say even Acrobat can't fill the forms), > or maybe it's no real form but just non-interactive > graphic in which case you would use typewriter > annotations to fill them. > > Feel free to open a poppler bug where you attach the PDF file, > so that we can have a look at it. > > Tobias > ___ > poppler mailing list > poppler@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/poppler -- -Alex ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
[poppler] A way to count the number of transparent objects
Hi all, I have a web page that generates tons of transparent objects in the print preview PDF. pdftocairo would grab 400% of RAM when trying to convert it to PostScript and die from the hands of OOM killer. Printer itself would just choke on the PDF if I send it directly. I wonder if there is a command-line way to count the number of transparent objects? This will allow me to catch them in the pipeline and process them differently. Ideally, maybe there is also a way to flatten the PDF somehow, merging those objects? I couldn't find anything in the poppler utils docs, hoping someone has any suggestions. Thanks. -- Alex ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Build fail on Ubuntu 14.04
That worked, thanks! On Thu, Sep 15, 2016 at 4:30 PM, Jason Crain <ja...@aquaticape.us> wrote: > On 2016-09-15, Alex Korobkin <korobkin...@gmail.com> wrote: > > poppler-document.cc:1521:25: error: invalid conversion from 'int' to > > 'GParamFlags' [-fpermissive] > > G_PARAM_READWRITE)); > ... > > Does it need a newer version of glib-2.0 since 0.47 release? Or am I > > missing something other library or reference? > > It needs a newer version of glib. See https://bugs.freedesktop.org/97432. > Old glib has G_PARAM_READWRITE as a #define and C++ doesn't like that. > -- -Alex ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
[poppler] Build fail on Ubuntu 14.04
Hi all, I'm trying to build poppler 0.47 on Ubuntu 14.04, and it fails with this error: poppler-document.cc: In function 'void poppler_document_class_init(PopplerDocumentClass*)': poppler-document.cc:1521:25: error: invalid conversion from 'int' to 'GParamFlags' [-fpermissive] G_PARAM_READWRITE)); ^ In file included from /usr/include/glib-2.0/glib-object.h:28:0, from poppler.h:22, from poppler-document.cc:41: /usr/include/glib-2.0/gobject/gparamspecs.h:1085:13: error: initializing argument 5 of 'GParamSpec* g_param_spec_string(const gchar*, const gchar*, const gchar*, const gchar*, GParamFlags)' [-fpermissive] GParamSpec* g_param_spec_string (const gchar *name, ^ poppler-document.cc:1573:25: error: invalid conversion from 'int' to 'GParamFlags' [-fpermissive] Does it need a newer version of glib-2.0 since 0.47 release? Or am I missing something other library or reference? Longer output: http://pastebin.com/wBdmL7GV -- -Alex ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Postscript native image resolution
I've switched from pdftops to pdftocairo three years ago and am mostly happy with it. It produces consistently good print jobs. Most serious bug so far is this one for me, where pdftocairo chokes on some PDFs and hogs one CPU for a very-very long time (I have a background job to kill it after 30 min). If you have a busy print-server, a couple of such jobs would take it down. https://bugs.freedesktop.org/show_bug.cgi?id=82963 Another bug is this one, but it affects both pdftocairo and pdftops for me. They produce a seemingly good PostScript, but Adobe PS engine in the printers chokes on it. Adobe never replied to my bug reports. https://bugs.freedesktop.org/show_bug.cgi?id=79897 On Wed, Jul 6, 2016 at 4:18 PM, Pierre-Luc Samuel < pierre-luc.sam...@ticketmaster.com> wrote: > OK I tested with pdftocairo and indeed the result is much better. I'm > kinda surprised though, I would have thought that pdftops would be more > specialized and generally better, but it doesn't seem so. > > Are there some pitfalls to using pdftocairo for postscript rendering? Are > there major differences compared to pdftops that I should be aware of? > > Thanks for the info, you guys are very helpful. > > Pierre-Luc > > > On 07/06/2016 08:10 AM, Adrian Johnson wrote: > >> pdftops does preserve the original resolution. However if the page >> contains anything that can't be converted directly to PostScript >> (usually transparency), the entire page is rasterized to a single >> fallback image with the resolution specified by -r. >> >> pdftocairo also preserves the original resolution. In the case where a >> fallback image is required, pdftocairo will only rasterize the parts of >> the page that can't be converted to PostScript. So if PDF images do not >> contain transparency they will always be output at their native >> resolution. >> >> There is a bug open to add support to pdftops for finer-grained >> fallbacks. But I'm not sure how to handle different color spaces. >> >>https://bugs.freedesktop.org/show_bug.cgi?id=66056 >> >> >> On 05/07/16 23:19, suzuki toshiya wrote: >> >>> Dear Pierre, >>> >>> Sorry for that I'm posting this before testing by myself, >>> have you take a look on pdftocairo? I remember, when I >>> convert a pdf to a svg, pdftocairo does not re-rasterize >>> the embedded raster image, so I expect PS output from >>> pdftocairo could be better for your purpose. >>> >>> Regards, >>> mpsuzuki >>> >>> Pierre-Luc Samuel wrote: >>> Hi, I've been wondering if there is a feature for pdftops that would convert pdf to postscript by keeping the original resolution of images embedded in the pdf? The problem I'm encountering is that my pdfs contain low res images that are stretched to be big; pdftops converts them by re-rasterizing the low res images so that they look smooth. The result is that my images now look extremely smooth, but the resulting postscript file size explodes. The issue I have with "-r " is that the native resolution of my images is about 150 dpi, but when using "-r 150", I get reasonable file sizes, but the text sections of the pdf becomes barely readable I would like to suggest a "-nativeimageres" option that would be independent of the existing "-r " option. Do you guys think a "-nativeimageres" option is technically possible? Could you give me indications where to start, in case I need to look deeper into this? Thanks, Pierre-Luc ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler >>> ___ >>> poppler mailing list >>> poppler@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/poppler >>> >>> ___ >> poppler mailing list >> poppler@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/poppler >> > > ___ > poppler mailing list > poppler@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/poppler > -- -Alex ___ poppler mailing list poppler@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Poppler 0.31.0 released
I cannot compile cups-filters 1.0.62 with this version of poppler, because getAntialias has been removed from GlobalParams class. Was that removal intentional or is it a bug? 2015-02-05 14:26 GMT-05:00 Albert Astals Cid aa...@kde.org: Meh subject was wrong, it's 0.31.0 not 0.30.1 Cheers, Albert El Dijous, 5 de febrer de 2015, a les 20:25:05, Albert Astals Cid va escriure: Available from http://poppler.freedesktop.org/poppler-0.31.0.tar.xz Changes against 0.30.0 include: core: * CairoOutputDev: support embedding JBIG2 image data * Accept malformed documents whose root is a Page instead of a Pages. Bug #88172 * Fix crash on broken documents * JPEG2000Stream: Inline doGetChar and doLookChar * GlobalParams cleaning utils: * pdftops: Add rasterization option. Bug #85934 qt4: * Expose whole-words search option qt5: * Expose whole-words search option Testing, patches and bug reports welcome. Cheers, Albert ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler -- -Alex ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] A question about xpdf
2014/1/16 suzuki toshiya mpsuz...@hiroshima-u.ac.jp Anyway, removal of xpdf package from Debian is a pity, I sympathize. I feel most of post-xpdf PDF viewers are slightly too heavy because of the binding with rich UI toolkits. Btw, mupdf is fast, cool, and looks similar to xpdf. -- -Alex ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Bug 69485
Adrian,
2014/1/6 Alex Korobkin korobkin...@gmail.com
Adrian,
2014/1/6 Adrian Johnson ajohn...@redneon.com
I was looking at the imagemask-with-pattern.ps test case in
http://bugs.ghostscript.com/show_bug.cgi?id=689818 and noticed the pop
in the /PaintProc.
Does this change fix the bug?
- /PaintProc { CairoPattern }
+ /PaintProc { pop CairoPattern }
Wow, it does indeed solve the problem for the Distiller! I can certainly
open my china-visa-application file in Distiller with this modification, no
errors reported and the document looks correct.
I cannot test with a Ricoh printer right now, will report tomorrow.
It certainly works with Ricoh printers, too.
There is a very minor side effect: it prints number of pages being
processed, and it used to be
PAGE: 1 1
PAGE: 2 1
PAGE: 3 1
PAGE: 4 1
%%[ Error: ...
Now it only reports three pages, not four,
PAGE: 1 1
PAGE: 2 1
PAGE: 3 1
But all four pages are correctly printed, so it's probably nothing to worry
about.
-Alex
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Bug 69485
2014/1/7 Adrian Johnson ajohn...@redneon.com
On 07/01/14 17:34, Ross Moore wrote:
Hi Alex,
On 07/01/2014, at 4:35 PM, Alex Korobkin wrote:
Hi Ross,
2014/1/5 Ross Moore ross.mo...@mq.edu.au
While we're on this subject, maybe you could have a look at the PS
output produced by pdftops, when processing the same file?
The resulting level 3 PostScript cannot be parsed by Distiller
either, the error is
%%[ Error: undefined; OffendingCommand: xyshow ]%%
OK. I can reproduce this.
Again ps2pdf has no problem with it, but Apple's pstopdf
also fails to do the conversion.
This is most perplexing as the xyshow command is handled
correctly 10 times, but fails on the 11th usage.
Just to be sure I understand this correctly: I only see xyshow being
used once in the document, when defining Tj macro.
That's correct.
Do you refer to the 11th invocation of Tj macro?
Yes.
I think this is called for each syllable or group of letters in each
word.
In particular I think it is called for each individual chinese character,
or a group of characters.
It seems that the difficulty is first encountered
when handling the chinese characters in the heading of
the Form.
(Preceding this are the characters of: Form V.2013
at top-right of page 1. These are done OK. )
Here's how I can check this:
% text string operators
/xyshow where {
pop
/xyshow2 {
dup length array
0 2 2 index length 1 sub {
2 index 1 index 2 copy get 3 1 roll 1 add get
pdfTextMat dtransform
4 2 roll 2 copy 6 5 roll put 1 add 3 1 roll dup 4 2 roll put
} for
exch pop
mark /xyshow where pstack cleartomark %--- insert this line
xyshow
} def
}{
/xyshow2 {
currentfont /FontType get 0 eq {
... etc ...
This causes the contents of the stack to be written to the Log
immediately before xyshow is called.
The indication is that xyshow is indeed well-defined,
yet something still goes wrong.
Thank you for the hint, I will try to do more debugging using this
technique.
Postscript has a few neat constructions that help with debugging.
Another, which might come in helpful here, is to use the 'stopped'
operator.
With this, you can cause messages to be printed to the log,
only when an error has been encountered. This kind of debugging
would most likely be using 'pstack', 'mark' and 'cleartomark'
if you want to see what was on the stack when the error occurs.
By commenting out groups of lines like this, I can process
further and further into the file.
Does it mean that the error is not caused by any particular call to
xyshow, but more likely by the number of such calls made consequently?
Maybe it is some kind of nesting issue, or stack not been freed
properly issue?
Not the number of calls.
There can be a large number of instances of xyshow between those
which fail, or they can be more or less adjacent.
I suspect that the character strings that xyshow is trying to set
are faulty in some way; that is, correspond to non-existent code-points
or glyphs within the subsetted font.
But I'm no expert on this, so it is pretty much guesswork.
I agree it is probably the character string. You could confirm this by
replacing the offsets array and Tj with show. eg
(A\361+cB'\230) show
Does it also fail if you convert to level 2 PS? The level 2 output uses
composite fonts instead of CID fonts for 16-bit fonts. If level 2 fails
the problem is more likely to be in the sfnt data. At this point you
need to convert the sfnt data to binary and examine it using tools like
showttf, ttx, and fontforge.
Yes, it fails with level 2 and produces exactly the same error.
Since the file works with ghostscript and some printers the problem
won't be something that is completely wrong like using a non existent
glyph. It will be something more subtle like incorrectly aligned data or
an invalid value in an optional field.
Let's summarize it:
When we convert china-visa-application.pdf to level 3 PostScript,
pdftocairo (with your patch), GhostScript, and Distiller all produce valid
PostScript that can be read by Distiller and printed by Ricoh printers. At
the same time, pdftops produces the PostScript that is huge in size and
cannot be read by Distiller, but looks to be valid.
I'm curious what does poppler pdftops do with fonts that makes such a
noticeable difference in the resulting file? Could anything be done to make
the resulting PostScript be more compatible with Adobe products?
-Alex
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Bug 69485
Adrian,
2014/1/6 Adrian Johnson ajohn...@redneon.com
I was looking at the imagemask-with-pattern.ps test case in
http://bugs.ghostscript.com/show_bug.cgi?id=689818 and noticed the pop
in the /PaintProc.
Does this change fix the bug?
- /PaintProc { CairoPattern }
+ /PaintProc { pop CairoPattern }
Wow, it does indeed solve the problem for the Distiller! I can certainly
open my china-visa-application file in Distiller with this modification, no
errors reported and the document looks correct.
I cannot test with a Ricoh printer right now, will report tomorrow.
-Alex
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Bug 69485
Hi Ross,
2014/1/5 Ross Moore ross.mo...@mq.edu.au
While we're on this subject, maybe you could have a look at the PS
output produced by pdftops, when processing the same file?
The resulting level 3 PostScript cannot be parsed by Distiller either,
the error is
%%[ Error: undefined; OffendingCommand: xyshow ]%%
OK. I can reproduce this.
Again ps2pdf has no problem with it, but Apple's pstopdf
also fails to do the conversion.
This is most perplexing as the xyshow command is handled
correctly 10 times, but fails on the 11th usage.
Just to be sure I understand this correctly: I only see xyshow being used
once in the document, when defining Tj macro.
Do you refer to the 11th invocation of Tj macro?
It seems that the difficulty is first encountered
when handling the chinese characters in the heading of
the Form.
(Preceding this are the characters of: Form V.2013
at top-right of page 1. These are done OK. )
Here's how I can check this:
% text string operators
/xyshow where {
pop
/xyshow2 {
dup length array
0 2 2 index length 1 sub {
2 index 1 index 2 copy get 3 1 roll 1 add get
pdfTextMat dtransform
4 2 roll 2 copy 6 5 roll put 1 add 3 1 roll dup 4 2 roll put
} for
exch pop
mark /xyshow where pstack cleartomark %--- insert this line
xyshow
} def
}{
/xyshow2 {
currentfont /FontType get 0 eq {
... etc ...
This causes the contents of the stack to be written to the Log
immediately before xyshow is called.
The indication is that xyshow is indeed well-defined,
yet something still goes wrong.
Thank you for the hint, I will try to do more debugging using this
technique.
Thus the error must be happening at an internal level,
not within the user-level PS coding.
Stack:
[26.046 0.0 26.046 0.0 26.046 0.0 26.046 0.0]
(Añ+cB'˜)
[1.447 0 1.447 0 1.447 0 1.447 0]
(Añ+cB'˜)
762.6
363.275
By commenting out groups of lines like this, I can process
further and further into the file.
Does it mean that the error is not caused by any particular call to xyshow,
but more likely by the number of such calls made consequently?
Maybe it is some kind of nesting issue, or stack not been freed properly
issue?
It seems that the errors occur with chinese characters,
always when coming from the font referenced as: /F243_0
which is:
/F243_0 /ZJWNJQ+SimSun 0 pdfMakeFont16L3
%%BeginResource: font ZJWNJQ+SimSun
%!PS-TrueTypeFont- 1
20 dict begin
/CIDFontName /ZJWNJQ+SimSun def
/CIDFontType 2 def
/FontType 42 def
/CIDSystemInfo 3 dict dup begin
/Registry (Adobe) def
/Ordering (Identity) def
/Supplement 0 def
end def
/GDBytes 2 def
/CIDCount 28762 def
/CIDMap 57524 string
0 1 28761 {
2 copy dup 2 mul exch -8 bitshift put
1 index exch dup 2 mul 1 add exch 255 and put
} for
def
/FontMatrix [1 0 0 1 0 0] def
/FontBBox [-2 -37 256 220] def
/PaintType 0 def
/Encoding [] readonly def
/CharStrings 1 dict dup begin
/.notdef 0 def
end readonly def
/sfnts [
0001000b0083003063767420072903f000bc02be6670676d
...
Thus it would seem that there could be something badly wrong
with this font, or with the way it is being used in this document.
Note carefully what I am saying here.
Not every instance of this font's usage causes an error,
but all the errors that I have found are associated with
an instance of this font's use.
The PS file can be retrieved from here, it is 18Mb in size. (Unlike
pdftocairo, pdftops generates huge PS files. This particular one gets 10x
larger when I provide licensed fonts to pdftops.)
Yes.
Almost all of the first 87% of the file is devoted to the fonts.
I kind of wonder why pdftops embeds so many instances of the font, while
both pdftocairo and pdf2ps somehow avoid this problem and create smaller PS
documents. But, that's a subject for another discussion.
https://docs.google.com/uc?export=downloadid=0B-vV7Qx5rjpEVWxVSWtFZU5UX2s
I suspect that there is a similar problem somewhere along the lines
284962-284999:
/DeviceGray {} CS
[0] SC
[0] SC
0.514 w
0.447 Tc
-0.447 Tw
2 Tr
[18 0 0 18 154.68 762.6] Tm
0 0 Td
/F243_0 1 Tf
(\004]\011~\004\352A)
[1.447
0
1.447
0
1.447
0
1.447
0] Tj
My very basic knowledge of PS doesn't allow be to get any deeper :(
I did not encounter a problem at this point in the file;
but yes this also corresponds to an instance of /F243_0 !
I only point to this location because it's the first mention of the [1.447
0 1.447 0 1.447 0 1.447 0] sequence, referred to by Distiller error
message. Perhaps I misinterpret Distiller's message.
Hope this helps,
It helps greatly, thanks again.
-Alex
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler
[poppler] Bug 69485
Hi team, Could someone please look into https://bugs.freedesktop.org/show_bug.cgi?id=69485 ? Documents similar to the one attached to the bug are unprintable due to this strange error, and I don't see what exactly is wrong with the document. Evince, Acrobat and other PDF viewers can read the original PDF just fine, but no one can print it. -Alex ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] Bug 69485
Yes, PDF seems to be fine, but Adobe Distiller and the printing engine of Ricoh printers cannot handle PS, produced by pdftops and pdftocairo (level 3). Ricoh says that if it cannot be read by Distiller, it won't be processed by printers. On 2 Jan 2014 18:01, Adrian Johnson ajohn...@redneon.com wrote: Leonard, Do you have any idea why Adobe Distiller fails on the PS output? The PS files print fine on my Xerox printer which has Adobe PS. On 03/01/14 08:56, Leonard Rosenthol wrote: Prints just fine from Adobe Acrobat on both Mac and Win. I validated both files using the PDF syntax checker in Acrobat and they both passed fine. So there is nothing wrong with the PDFs in question. Leonard From: Alex Korobkin korobkin...@gmail.com mailto:korobkin...@gmail.com Date: Thursday, January 2, 2014 5:17 PM To: poppler@lists.freedesktop.org mailto:poppler@lists.freedesktop.org poppler@lists.freedesktop.org mailto:poppler@lists.freedesktop.org Subject: [poppler] Bug 69485 Hi team, Could someone please look into https://bugs.freedesktop.org/show_bug.cgi?id=69485 ? Documents similar to the one attached to the bug are unprintable due to this strange error, and I don't see what exactly is wrong with the document. Evince, Acrobat and other PDF viewers can read the original PDF just fine, but no one can print it. -Alex ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler
[poppler] What is wrong with this piece of PostScript code?
Hi all,
I have a PostScript file generated from a PDF by pdftops 0.22.3, which
cannot be interpreted neither by printer nor by GhostScript. I figured that
removing this stance of code (marked with ) makes GhostScript happy, but
cannot understand what exactly is wrong with it.
Here is the code:
0 0 Td
[1 0 0 -1 139 18] Tm
0 0 Td
/F12_0 13. Tf
(\012\355)
[13.
0] Tj
[1 0 0 1 0 0] Tm
0 0 Td
[1 0 0 -1 139 18] Tm
0 0 Td
/F11_0 13. Tf
(\000\003)
[3.704417
F12_0 represents embedded DejaVuSans font.
I assume that Tj is a standard procedure inserted by poppler, but will copy
it here just in case:
/Tj {
fCol
0 pdfTextRise pdfTextMat dtransform rmoveto
currentpoint 4 2 roll
pdfTextRender 1 and 0 eq {
2 copy xyshow2
} if
pdfTextRender 3 and dup 1 eq exch 2 eq or {
3 index 3 index moveto
2 copy
currentfont /FontType get 3 eq { fCol } { sCol } ifelse
xycp currentpoint stroke moveto
} if
pdfTextRender 4 and 0 ne {
4 2 roll moveto xycp
/pdfTextClipPath [ pdfTextClipPath aload pop
{/moveto cvx}
{/lineto cvx}
{/curveto cvx}
{/closepath cvx}
pathforall ] def
currentpoint newpath moveto
} {
pop pop pop pop
} ifelse
0 pdfTextRise neg pdfTextMat dtransform rmoveto
} def
Here is how GhostScript complains about it:
...
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
I assume the problem is with how the original PDF embeds the font, but
cannot really understand why Tj would fail on those parameters.
Could someone please have a look and give me a hint on why is this
happening?
Thanks in advance.
Unfortunately, the original doc cannot be provided because it's full of
confidential information.
___
poppler mailing list
poppler@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler
Re: [poppler] poppler 0.21.4 fails to build with cairo 1.12.8 for me
Sorry, please disregard it all, somehow it now builds nicely with both cairo 1.10 and 1.12.8. I'm building in a clean pbuilder environment with no preinstalled packages, and I didn't make any changes to it, this is why I'm unsure why it works now. But looks like it is all good. Thanks for looking into it. On 27 December 2012 19:37, Adrian Johnson ajohn...@redneon.com wrote: On 28/12/12 06:49, Alex Korobkin wrote: Offending line seems to be: CairoOutputDev.h:233:16: error: 'virtual void CairoOutputDev::setSoftMaskFromImageMask(GfxState*, Object*, Stream*, int, int, GBool, GBool, double*)' cannot be overloaded My copy of 0.21.4 does not have setSoftMaskFromImageMask at line 233 of CairoOutputDev.h. Does poppler 0.21.4 work with Cairo 1.12.8 for anyone? Works for me with cairo 1.12.8 on Ubuntu 12.10. Do you have any hints on why would it complain about such overloading problem? I have had linking problems when there is already a previously installed copy of poppler in the install location (only occurs when glib introspection is enabled). But your problem seems to be occurring at the compile stage. ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler
[poppler] poppler 0.21.4 fails to build with cairo 1.12.8 for me
Hi all, I'm building poppler 0.21.4 on Ubuntu 12.04 x64, with freshly built and installed cairo 1.12.8. This is what I see during the building process: libtool: link: ( cd .libs rm -f libpoppler.la ln -s ../libpoppler.la libpoppler.la ) /bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../goo -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/libpng12 -I/usr/include/freetype2 -D_FORTIFY_SOURCE=2 -Wall -Woverloaded-virtual -Wnon-virtual-dtor -Wcast-align -fno-exceptions -fno-check-new -fno-common -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -ansi -pthread -c -o CairoFontEngine.lo CairoFontEngine.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I../goo -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtXml -I/usr/include/libpng12 -I/usr/include/freetype2 -D_FORTIFY_SOURCE=2 -Wall -Woverloaded-virtual -Wnon-virtual-dtor -Wcast-align -fno-exceptions -fno-check-new -fno-common -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -ansi -pthread -c CairoFontEngine.cc -fPIC -DPIC -o .libs/CairoFontEngine.o In file included from CairoFontEngine.cc:40:0: CairoOutputDev.h:233:16: error: 'virtual void CairoOutputDev::setSoftMaskFromImageMask(GfxState*, Object*, Stream*, int, int, GBool, GBool, double*)' cannot be overloaded CairoOutputDev.h:202:16: error: with 'virtual void CairoOutputDev::setSoftMaskFromImageMask(GfxState*, Object*, Stream*, int, int, GBool, GBool, double*)' CairoOutputDev.h:236:16: error: 'virtual void CairoOutputDev::unsetSoftMaskFromImageMask(GfxState*, double*)' cannot be overloaded CairoOutputDev.h:206:16: error: with 'virtual void CairoOutputDev::unsetSoftMaskFromImageMask(GfxState*, double*)' make[4]: *** [CairoFontEngine.lo] Error 1 make[4]: Leaving directory `/tmp/buildd/poppler-0.21.4/poppler' Offending line seems to be: CairoOutputDev.h:233:16: error: 'virtual void CairoOutputDev::setSoftMaskFromImageMask(GfxState*, Object*, Stream*, int, int, GBool, GBool, double*)' cannot be overloaded Does poppler 0.21.4 work with Cairo 1.12.8 for anyone? Do you have any hints on why would it complain about such overloading problem? ___ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler
