http://sarovar.org/download.php/846/pdftex-1.40.0-alpha-20051205.tar.bz2 I've tried to intergrate as many patches as possible: - 386 grow obj_tab and dest_names arrays dynamically - 416 new primitive pdflastlink - 427 Character positioning patch - 432 Rules in a PDF qQ group - 434 Remove queued map item handling - 438 \pdfsavepos in DVI mode - 443 512 zeros in Type1 fonts not copied anymore - 447 Don't write /Encoding for non-reencoded fonts - 453 Object Streams for PDF-1.5 - take PK resolution from "pk_dpi" parameter in texmfmp.c, if it has not been set by the format file or by the user It's roughly tested: The manual still compiles. Best Martin -- http://www.tm.oneiros.de
On Mon, 5 Dec 2005, Martin Schröder wrote:
- take PK resolution from "pk_dpi" parameter in texmfmp.c, if it has not been set by the format file or by the user
ooops, my mistake, it should be: - take PK resolution from "pk_dpi" parameter in texmf.cnf, if it has not been set by the format file or by the user ...and once the pk_dpi value is in texmf.cnf, also other programs can make use of it, and there is then also no need anymore to state the \pdfpkresolution in pdftexconfig.tex. Regards, Hartmut
Martin Schröder napisał(a):
http://sarovar.org/download.php/846/pdftex-1.40.0-alpha-20051205.tar.bz2 [...] It's roughly tested: The manual still compiles.
But samplepdf doesn't compile. Runaway argument? ! Paragraph ended before \handleMPsequence was complete. <to be read again> \par l.2 I haven't touch this part at all. Has anybody? BR, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Pawel Jackowski wrote:
Martin Schr�der napisa�(a):
http://sarovar.org/download.php/846/pdftex-1.40.0-alpha-20051205.tar.bz2
[...]
It's roughly tested: The manual still compiles.
But samplepdf doesn't compile.
Runaway argument? ! Paragraph ended before \handleMPsequence was complete. <to be read again> \par l.2
I haven't touch this part at all. Has anybody?
(1) maybe clean-up old mpgraph.* files (2) maybe your format uses an old supp-pdf (somewhere else in the three) with a new context there has been a change (in metafun) with regards to the amount of special things (jump from 1K to 10K) but this is (if i'm right) made in an upward compatible way Hans
Hi there,
I haven't touch this part at all. Has anybody?
Hans:
(1) maybe clean-up old mpgraph.* files (2) maybe your format uses an old supp-pdf (somewhere else in the three) with a new context
there has been a change (in metafun) with regards to the amount of special things (jump from 1K to 10K) but this is (if i'm right) made in an upward compatible way
Agh, trivial problem; cvs checkout with wrong endline characters; ConTeXt macro crashes on double \n. Sorry for noise. BTW, should I update supp-*.tex stuff? CVS/samplepdf has version 2004.10.26. Hartmut:
...but it does _not_ work with \pdfobjectstreams=1:
hahe@hahepc2:~/x-sa/samplepdf$ xpdf samplepdf.pdf Error (706458): Illegal character <2f> in hex string Error (706459): Illegal character <54> in hex string Error (706460): Illegal character <79> in hex string Error (706461): Illegal character <70> in hex string Error (706464): Illegal character <2f> in hex string
So that is something different; my problem was surely because of endlines. Now I add \pdfobjectstreams=1 at the very begining of samplepdf.tex and the output is damaged indeed. Haven't look inside but crashes on Acrobat and GhostScript while opening. BUT even with \pdfobjectstreams=0 % or simply commented the output crashes on GhostScript. Acrobat complains but manage to fix the problem. Tested on 1.40.0-alpha compiled with Cygwin. BR, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
On Mon, 5 Dec 2005, Martin Schröder wrote:
http://sarovar.org/download.php/846/pdftex-1.40.0-alpha-20051205.tar.bz2
I've tried to intergrate as many patches as possible: - 386 grow obj_tab and dest_names arrays dynamically
this 386 is not yet included, there were two conflicting patches. I will integrate it into a fresh 453 patch.
It's roughly tested: The manual still compiles.
As Pawe/l found, compiling samplepdf.tex leads to acroread and gs crashes. Reason 1: the first dictionary was written before the PDF-1.5 string. Compare to pdf_begin_obj: procedure pdf_begin_dict(i: integer; pdf_os: boolean); {begin a PDF dictionary object} begin check_pdfminorversion; {<--- this line was missing} pdf_os_prepare_obj(i, pdf_os); This will be repaired in the next patch. Now comes the interesting part: The reason 2 why Acroread and gs still crash (but not xpdf :-) ist this harmless looking object, 4 0 obj: Hello created by \pdfobj{Hello} \pdfrefobj \pdflastobj This "object" is self-standing, not referenced from anywhere. This seems to be completely legal in PDF-1.4. But when Acroread or gs find it within an object stream, and everything really looks ok AFAICT, both just choke. It works ok, when i simply write \pdfobj{(Hello)} instead of \pdfobj{Hello}. And no hint in the PDF Reference. My guess is that when an object stream is used, certain types are given to an object, e. g. <<...>> or [...] or (...) which all means something, but a simple Hello gives problems. Anybody any idea about this? What do with such a solitary Hello? Regards, Hartmut
ok, now it seems that \pdfobj{Hello} does not create a legal PDF object, as it's none of the eight types described in the PDF Reference section 3.2. E. g., a cross check shows that \pdfobj{false} is ok, a boolean value, while \pdfobj{maybe} does not work :-) Regards, Hartmut
Hartmut,
ok, now it seems that \pdfobj{Hello} does not create a legal PDF object, as it's none of the eight types described in the PDF Reference section 3.2. E. g., a cross check shows that \pdfobj{false} is ok, a boolean value, while \pdfobj{maybe} does not work :-)
My tests show the same. An object 10 0 obj Hello endobj is not correct, but parsers ignores it if don't have to read it. I opened such a document in Acrobat and tried to save it as PDF1.5 (which instructs Acrobat to compress objects). Then it complains loudly. So, in samplepdf I will replace all Hello with <<Hello>>, (Hello), [Hello] and make a note about the danger. Thanks, -- Pawe/l Jackowski P.Jackowski@gust.org.pl
On 05.12.2005 00:39, Martin Schröder wrote:
It's roughly tested: The manual still compiles.
I get a segfault with the following: \pdfcompresslevel=0 \documentclass{minimal} \usepackage{multicol} \usepackage{hyperref} \begin{document} Numbers written in italic refer to the page where the corresponding entry is described; numbers underlined refer to the code \begin{multicols}{2} x\hyperpage{1} \end{multicols} \end{document} When changing the text above ever so slightly, it will compile, however, there still won't be a link in the PDF. (Its object number is zero.) Regards, Robert.
Hi Robert and Ralf, On Thu, 8 Dec 2005 w.m.l@gmx.net wrote:
On 05.12.2005 00:39, Martin Schröder wrote:
It's roughly tested: The manual still compiles.
I get a segfault with the following:
\pdfcompresslevel=0 \documentclass{minimal} \usepackage{multicol} \usepackage{hyperref} \begin{document} Numbers written in italic refer to the page where the corresponding entry is described; numbers underlined refer to the code \begin{multicols}{2} x\hyperpage{1} \end{multicols} \end{document}
When changing the text above ever so slightly, it will compile, however, there still won't be a link in the PDF. (Its object number is zero.)
thanks for testing. Seems to be in the pdflastlink change file, somehow related to the replacement of obj_annot_ptr(obj_ptr) := p; by obj_annot_ptr(pdf_link_objnum(p)) := p; in do_link(). The original made sense, as the obj_ptr was just freshly created. But no idea what the patched code does, which does not use obj_ptr (shouldn't it?). The macros resolved look like: obj_annot_ptr(pdf_link_objnum(p)) := p; obj_aux(pdf_link_objnum(p)) := p; obj_tab[pdf_link_objnum(p)].int4 := p; obj_tab[mem[p+6].int].int4 := p; This is one for Ralf... Regards, Hartmut
Hi, Hartmut Henkel wrote:
thanks for testing. Seems to be in the pdflastlink change file, somehow related to the replacement of
obj_annot_ptr(obj_ptr) := p;
I think I've found the cause of the problem, and it is not the change
file itself; that just drew another bug to the surface.
It turns out that when copying node lists, the sixth field of an annot
whatsit was never copied, and that's field that is used to store
the object number for \pdflastlink and \pdflastannot. Hence the copied
one was never properly initialized.
I've attached a new version of pdflastlink.ch that has three changes
compared to the one by Ralf:
* The quoted bits of web are a bit larger, so it reads a bit easier
* I've added a section of the @
Hi, Taco Hoekwater wrote: [...]
I've attached a new version of pdflastlink.ch that has three changes compared to the one by Ralf:
* The quoted bits of web are a bit larger, so it reads a bit easier * I've added a section of the @
, to copy the pdf_link_objnum() field * There was no need for pdf_create_obj() in do_link any more.
[...] thanks a lot for looking into this and fixing it. I tested with a form file where I need pdflastlink and it still works without problem with this new change file. Bye, Ralf -- Ralf Utermann _____________________________________________________________________ Universität Augsburg, Institut für Physik -- EDV-Betreuer Universitätsstr.1 D-86135 Augsburg Phone: +49-821-598-3231 SMTP: Ralf.Utermann@Physik.Uni-Augsburg.DE Fax: -3411
participants (7)
-
Hans Hagen
-
Hartmut Henkel
-
Martin Schröder
-
Pawel Jackowski
-
Ralf Utermann
-
Taco Hoekwater
-
w.m.l@gmx.net