search

zackw / pdfsizeopt

Automatically exported from code.google.com/p/pdfsizeopt
0 stars 0 forks source link

Borders of hyperref-package are not shown after optimization of PDF #53

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What command do you run to optimize the PDF?

python [path to]/pdfsizeopt.py minimal.pdf

What does pdfsizeopt display when running the command above?

info: This is pdfsizeopt.py rUNKNOWN size=280345.
info: loading PDF from: minimal.pdf
info: loaded PDF of 13411 bytes
info: separated to 16 objs + xref + trailer
info: found 1 Type1 fonts loaded
info: writing Type1CConverter (10901 font bytes) to: pso.conv.tmp.ps
info: executing Type1CConverter with Ghostscript: gs -q -dNOPAUSE -dBATCH 
-sDEVICE=pdfwrite -dPDFSETTINGS=/printer 
-dColorConversionStrategy=/LeaveColorUnchanged -sOutputFile=pso.conv.tmp.pdf -f 
pso.conv.tmp.ps
Type1CConverter: using interpreter GPL Ghostscript 871 20100210
Type1CConverter: converting font /YEVXFT+CMTT10 to /Obj0000000012
Type1CConverter: all OK
info: loading PDF from: pso.conv.tmp.pdf
info: loaded PDF of 5070 bytes
info: separated to 13 objs + xref + trailer
info: found 1 fonts in GS output
info: optimized total Type1 font size 10874 to Type1C font size 1828 (17%)
info: optimized Type1 font XObject 12,11: new size=2103 (19%)
info: found 1 Type1C fonts loaded
info: writing Type1CParser (1842 font bytes) to: pso.conv.parse.tmp.ps
info: executing Type1CParser with Ghostscript: gs -q -dNOPAUSE -dBATCH 
-sDEVICE=nullpage -sDataFile=pso.conv.parsedata.tmp.ps -f pso.conv.parse.tmp.ps
Type1CParser: using interpreter GPL Ghostscript 871 20100210
Type1CParser: all OK
info: parsed 1 Type1C fonts
info: writing Multivalent input PDF: pso.conv.mi.tmp.pdf
info: saving PDF with 16 objs to: pso.conv.mi.tmp.pdf
info: generated 3875 bytes (29%)
info: executing Multivalent to optimize PDF: java -cp 
/home/michel/loc_inst/pdfsizeopt/Multivalent.jar tool.pdf.Compress -nopagepiece 
-noalt pso.conv.mi.tmp.pdf
file:/tmp/pso.conv.mi.tmp.pdf, 3875 bytes
PDF 1.5, producer=pdfTeX-1.40.10, creator=LaTeX with hyperref package
additional compression may be possible with:
     -compact
=> new length = 3792, saved 2%, elapsed time = 0 sec
info: Multivalent generated pso.conv.mi.tmp-o.pdf of 3813 bytes (98%)
info: compressed xref stream from 36 to 153 bytes (425%)
info: optimized to 3733 bytes after Multivalent (98%)
info: saving PDF to: minimal.psom.pdf
info: generated 3733 bytes (28%)

What's wrong with the optimized PDF?

The original file shows borders around the link. In the optimized file those 
borders are not shown anymore; the link works though. I use evince and okular 
to display the file.

What should be there in the optimized PDF instead?

The optimized PDF should behave just as the non-optimized one, i.e. the borders 
should be shown.

Original issue reported on code.google.com by m.vossku...@gmail.com on 6 Dec 2011 at 6:23

Attachments:

GoogleCodeExporter commented 8 years ago 
Thank you for finding and reporting this bug. I could reproduce the problem 
using the minimal.pdf you have attached.

When specifying the pdfsizeopt flag --use-multivalent=false , the generated 
minimal.pso.pdf file does contain the border, so I suspect that this issue is 
because of a bug or misconfiguration in Multivalent.

I'll take a look if I can fix the issue from the pdfsizeopt size, effectively 
preventing Multivalent from removing the border. I'll write an update as soon 
as I have anything to report. In the meantime, please use the following 
invocation as a workaround:

  pdfsizeopt.py --use-multivalent=false minimal.pdf

Please note that disabling Multivalent has some side effects, e.g. the 
resulting PDF will be a bit larger.

Original comment by pts...@gmail.com on 2 Apr 2012 at 5:56

GoogleCodeExporter commented 8 years ago 
FYI I could create a smaller example PDF file (minilink.pdf) which exposes the 
problem, see it attached. I used the following .tex source and pdflatex to 
generate the first version of minilink.pdf (and then I tweaked it by hand):

  \pdfcompresslevel9
  \documentclass{article}
  \paperwidth2in \paperheight2in
  \pdfpagewidth\paperwidth \pdfpageheight\paperheight
  \usepackage{hyperref}
  \begin{document}
  \shipout\hbox{\href{http://example.org/}{\vrule
  width1ex height1ex}}
  \end{document}

FYI xpdf 3.02 and gv with Ghostscript 8.71 always display the border, but 
evince 2.30.3 doesn't. So I'm using evince for future diagnostics.

According to the following invocations, it seems to be that evince doesn't 
display the border when Multivalent is involved:

  pdfsizeopt.py --use-multivalent=false minilink.pdf  # minilink.pso.pdf has border.
  pdfsizeopt.py --use-multivalent=true  minilink.pdf  # minilink.psom.pdf is missing the border.
  java -cp Multivalent20060102.jar tool.pdf.Compress minilink.pdf  # minilink-o.pdf is missing the border.
  java -cp Multivalent20060102.jar tool.pdf.Compress -old minilink.pdf  # minilink-o.pdf is missing the border.

I've attached minilink-o.pdf, which is the output of Multivalent with the 
`-old' flag.

Comparing minilink.pdf and minilink-o.pdf manually was feasible because they 
were very small. It seems that Multivalent removes `/Border [0 0 1]' from `3 0 
obj' (which is the /Type/Annot /Subtype/Link). Adding that back manually makes 
the border appear again in evince.

The PDF reference 1.7 says that `/Border [0 0 1]' is optional, so Multivalent 
didn't make a mistake by removing it. So there is no bug in Multivalent or 
pdfsizeopt. The proper solution for this issue would be reporting this as a bug 
in evince (or libpoppler). Please report it, and add a link their issue tracker 
item here.

I haven't decided yet if I want to add a disabled-by-default command-line flag 
to pdfsizeopt.py to work around this Evince issue. I'll write an update once I 
have made up my mind.

Original comment by pts...@gmail.com on 2 Apr 2012 at 7:28

Attachments: