Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

perfect pdf from fop if seen with xpdf/evince, not so with acroread/gv 1

Status
Not open for further replies.

stefanwagner

Programmer
Oct 19, 2003
2,373
DE
I create a pdf with xsl/fo from my javaprogram, or produce a fo-file, and render it to pdf with an xsl-file.

Looking at it with xpdf or evince, it looks perfectly well, and I don't get an errormessage, neither while producing the pdf, nor while looking at it.

But customers complain that they see nothing, empty pdfs, and they use acrobat. Opening the file with gv (ghostview) leads to errormessages and it doesn't display content too - just the bookmarks.

I get this error-message (I inserted some newlines, to make it better readable):
Error: /unknownerror in --stroke--
Operand stack:
--dict:8/17(L)-- 139.607 0.7085
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-- GPL Ghostscript GPL Ghostscript 8.708.70: : Unrecoverable error, exit code 1
Unrecoverable error, exit code 1
2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1
%stopped_push --nostringval-- --nostringval-- --nostringval--
%array_continue --nostringval-- false 1 %stopped_push --nostringval--
%loop_continue --nostringval-- --nostringval--
Dictionary stack:
--dict:1156/1684(ro)(G)-- --dict:1/20(G)-- --dict:75/200(L)-- --dict:106/127(ro)(G)--
--dict:285/300(ro)(G)-- --dict:22/25(L)-- --dict:4/6(L)-- --dict:21/40(L)--
--dict:6/15(L)-- --dict:1/1(ro)(G)-- --dict:3/5(L)--
Current allocation mode is local
but it doesn't give me the simplest idea, what the problem is; I'm not even sure whether it is the same, causing invisible PDFs on Windows/acroread.

Switching from fop-0.95 to fop-1.0 didn't help.

Reformating the pdf with pdfcrop and pdfopt didn't help too.

don't visit my homepage:
 
Is it on windows, or at least at one instance of testing? If yes, try append explicit path to each file:
[tt] <path1>\fop.bat <path2>\abc.fo <path3>\xyz.pdf[/tt]
Rely on fop.bat where necessary classpath is setup for the session.
 
I'm not sure whether I got your question (I'm not native speaker). Especially I don't understand 'at one instance of testing'. But there is more.

I don't have a problem generating the pdf - it get's generated without errormessage (and no, on linux, not windows).

The pdf, if viewn with xpdf or evince, looks allright. Just ghostview produces the errormessage shown above, and displays empty pages.
And customers on the windows-platform complain not being able to view the pdf with Acroread threre.

So I guessed there is a different interpretation of the PDF-Format in the xpdf/evince-camp and in the gv/acroread teams.

But now I downloaded acroread for linux, where it's looking good as well. I have to ask, which version of acroread the windows-users are using.

I later rephrased my question, including more code here:

don't visit my homepage:
 
I run a quick test with the cutdown fo. I supply it with my own png. I produce a pdf read without error with acroread v9.4.1. The run is on fop 0.95.
 
Thank you, and sorry for the missing png. Version 9.4.1 is the same I have (on linux) - maybe the users have a rather old version? I'm still curious what the reason is, since, as you might agree, there is no fancy element involved - just a table, which contains a png.

thank's anyhow.

don't visit my homepage:
 
I'd try generating the pdf on windows, maybe it can point you in some direction.

Cheers,
Dian
 
a) I don't have windows.
b) The programs involved are java-programs, and I wouldn't expect any difference in running them on windows.
c) In production, they will allways be generated on linux, and viewn - mostly on windows.
d) tsuji - if I understand him correctly and read his profile the right way - did generate such an pdf on windows.
e) but you're welcome.

don't visit my homepage:
 
Hi again. Yes, I do have tested positively on windows.

A couple of things I might want to add though. Looking at the cutdown fo, I want make some remarks:

[1] The columns 2,3 and 4 are very "narrow". It has probably space to hold 0 to 2 characters. More, it would be overflowing it.

[2] I do additional test, fop does issue warnings on windows (would it be same on *nix? and warning only rather than more severe exception?) if I put some contents of length >=3 to them, although, it still generates apparently fine pdf with overlapping characters them. Pay some attention to the other tables not shown see if it systematically overflows them.

[3] I would suggest that when there are empty fo:block in the fo:table-cell, you generate the fo with an unbreakable space (&#xa0;) there instead. Your empty fo:block's have no style. In html analogy, the cell would collapse. Put an unbreakable space is a common practice to make the alignment comfortable. (Also restore them same style as other column so that you can see more clearly the alignment.)

After taking into account of the above, see if you generate generally readable pdf?
 
1) Columns 2, 3, and especially 4 are a bit narrow.

Column 2 will contain values from 0% to 100% without fraction, which is a maximum of 4 characters.
Column 3 will contain values from 0 to far less than 999, but more than 100, which is a maximum of 3 characters.

They fit well into those columns.
No. 4 is just there, because column 3 is right aligned, and column 5 is left aligned, and they will stick together, if I don't put an artificial column in between them. I had this before.

Here is a bigger fo-file, 2 pages output, 60kb: and the corresponding pdf (12 kb, broken for acroread) and (15 kb and ok with acroread, made via ps: fop -> ps -> ps2pdf) , which gives a much better impression of what is desired, than the 2-line table in the first and smallest example.

There is enogh room in every case.

2) Nothing overflows, ever. Are you sure about your claim ">=3 characters"? Since "100%" is already 4 characters, and fits well, and even "9999%" would fit, but never happen.

3) In html, due to my experience, I don't need an &nbsp; in empty table cells, if the width is declared. And - producing the pdf-file via ps:

Code:
fop -fo sample.fo -ps sample.ps 
ps2pdf sample.ps sample.pdf 
# opposed to
fop -fo sample.fo -pdf sample-direkt.pdf
- via ps, it produces an workable pdf for acroread, but without that, the sample-direkt.pdf, it's broken, though viewn with xpdf they look exactly the same.


don't visit my homepage:
 
[2.1] When I said narrow and the characters those columns could hold, I tried to convey something qualitative only. You are right to point that 4 characters etc for column 2 etc... If that is not the problem, keep the same script you've: that seems to have no problem in that regard...

[4] Now, the problem as I see it. In the row where you try to draw 0% graph, you've to, despite all, give some non-zero content-width attribute. Hence, the first encounter of such situation would be this.
[tt]
<fo:block id='frage-4'
padding-top='9pt'
keep-together.within-page='always'
text-align='start'>4. Sind Sie weiblich oder männlich?
<fo:table border-width='0.5mm'
border-style='solid'
table-layout='fixed'
width='100%'>
<fo:table-column column-width='25%'/>
<fo:table-column column-width= '8%'/>
<fo:table-column column-width= '7%'/>
<fo:table-column column-width= '2%'/>
<fo:table-column column-width='58%'/>
<fo:table-body>
<fo:table-row>
<fo:table-cell>
<fo:block>
<fo:external-graphic
src='./0.dot.png'
content-height='8pt'
scaling='non-uniform'
content-width='0[red].001[/red]'/>
</fo:block>
[blue]<!-- etc etc -->[/blue]
</fo:table-cell>
</fo:table-row>
[blue]<!-- etc etc -->[/blue]
</fo:table-body>
</fo:table>
[/tt]
[4.1] I give the content-width a reasonably small to make oneself happy for its meaning being treated as zero, but still number-wise non-zero to make the engine happy. Modify everywhere where 0% is meant for the graphic. It would then produce a well-behaved pdf and visually sacrifies nothing. Try it in your linux?
 
awesome! I guess that's it.

Code:
sed "s/content-width='0'/content-width='0.001'/" sample.fo > sample-0.01.fo
fop sample-0.01.fo sample-0.01-direkt.pdf
That works, and produces an acrobat-friendly pdf. I don't like the solution much, because it seems to enforce an additional step.

But if it is the solution - it is.

Thanks, very much.


don't visit my homepage:
 
>it seems to enforce an additional step.
That logic can be scripted in the transformation producing the fo. That can still be done seamless.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top