My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 53: Borders of hyperref-package are not shown after optimization of PDF
1 person starred this issue and may be notified of changes. Back to list
Status:  Accepted
Owner:  pts...@gmail.com


 
Reported by m.vossku...@gmail.com, Dec 6, 2011
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.
minimal.pdf
13.1 KB   Download
Apr 2, 2012
Project Member #1 pts...@gmail.com
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.
Status: Accepted
Labels: -Priority-High Priority-Critical
Apr 2, 2012
Project Member #2 pts...@gmail.com
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.
minilink.pdf
983 bytes   Download
minilink-o.pdf
953 bytes   Download

Powered by Google Project Hosting