December 2002 - ntg-pdftex - NTG Mailing Lists

Marking prereleases
by Martin Schroeder 16 Jan '03

16 Jan '03

Hi, although we have not yet release 1.10a, versions of 1.10a-devel are distributed with e.g. the latest tetex-beta (and I suspect fptex and miktex). Since we don't want to close the repository to the public, we need a way to mark these prereleases. This can be done automatically: We encode $DateTime$ into the version stamp of developement versions and the files containing the version stamp are automatically submitted periodically (e.g. weekly) to the repository. Better ideas? Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

9 55

Re: [pdftex] AR5 "Fit visible" bug
by Martin Schroeder 15 Jan '03

15 Jan '03

On 2002-05-26 02:02:48 +0200, Heiko Oberdiek wrote: > look at the following simple LaTeX file: > > \documentclass[a4paper]{article} > \begin{document} > \section{Hello World} > The begin of the line\hfill the end of the line > \end{document} > > run it through pdflatex and view the result > in the new version 5 of AcrobatReader/Unix. > With the view mode "Fit visible" the result > is very poor. The visible area is misplaced > by a large amount. > > Because "Fit visible" is my favourite view mode, > this misbehaviour would prevent me from using > AcrobatReader 5. Therefore I experimented to detect > the cause of the problem: > > * If there are lines (in the header, box around > the page), then the right margin is correct > calculated by AR, but the left margin is > zero. > * A box without any text is correctly displayed. > > The start of the pdf page stream: > > stream > 1 0 0 1 124.802 706.129 cm > BT > /F17 14.346 Tf 0 0 Td > [(1)-1125(H)1(ell)1(o)-375(W)94(orld)]TJ ... > > The problem seems, that AR does not take the current > transfer matrix (CTM) into account, if it scans the > first Td operator in a BT..ET block while calculating > the visible area. > > So the following fixes the problem in horizontal direction: > > 1 0 0 1 0 706.129 cm > BT > /F17 14.346 Tf 124.802 0 Td > [(1)-1125(H)1(ell)1(o)-375(W)94(orld)]TJ ... > > Some experiments (switching the view in AR) show > that also the vertical component has to be > fixed. > > Therefore I have written a suggestion for a patch > of pdfTeX, TeX/texk/web2c/pdftexdir/pdftex.ch: > > The "cm" command before "BT" is written > by pdf_begin_text in pdftexdir/pdftex.ch > by pdf_set_origin. So the patch sets > the current position to the lower left > corner during the call of pdf_set_origin, > so that the "cm" commands moves to 0,0 > before "BT". Then the parameter values > of the first "Td" will not be calculated > as "0 0", but contain the distance > to the lower left corner, so that AR5 is > happy. > There remains some obscure calculation > errors, eg. the detection of the right > margin, if there is only a few words, > but for normal pages the AR5 should now > usable in "Fit visible" view. > > If the example above is compiled with > dvips/ps2pdf or VTeX, then the pdf file > shows no such displacement. So users will > think, that pdfTeX is not able to generate > code that can be viewed properly and not > consider this as clear bug of AR5. > Therefore I see no way to avoid such a fix. > > Here my suggestion: > > *** pdftex.ch.org Sun May 26 00:04:44 2002 > --- pdftex.ch Sun May 26 00:04:53 2002 > *************** > *** 1519,1527 **** > --- 1519,1534 ---- > end; > > procedure pdf_begin_text; {begin a text section} > + var temp_cur_h, temp_cur_v: scaled; > begin > if not pdf_doing_text then begin > + temp_cur_h := cur_h; > + temp_cur_v := cur_v; > + cur_h := 0; > + cur_v := cur_page_height; > pdf_set_origin; > + cur_h := temp_cur_h; > + cur_v := temp_cur_v; > pdf_print_ln("BT"); > pdf_doing_text := true; > pdf_f := null_font; I'm just scanning through my pdftex mailbox and found this. What became of it? It certainly isn't in the source yet. Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

3 11

patch1 for xpdf-2.01
by Thomas Esser 28 Dec '02

28 Dec '02

Hi, I just have found that a fix for xpdf-2.01 is available: CTAN:support/xpdf/xpdf-2.01-patch1 It is quite short, so I have added it to this mail. Thomas Index: GfxState.cc =================================================================== RCS file: /home/derekn/src/cvs/xpdf/GfxState.cc,v retrieving revision 1.52 retrieving revision 1.55 diff -c -r1.52 -r1.55 *** GfxState.cc 21 Nov 2002 18:55:57 -0000 1.52 --- GfxState.cc 16 Dec 2002 21:57:13 -0000 1.55 *************** *** 815,823 **** --- 815,833 ---- obj1.free(); if (!arr->get(2, &obj1)->isInt()) { error(-1, "Bad Indexed color space (hival)"); + delete baseA; goto err2; } indexHighA = obj1.getInt(); + if (indexHighA < 0 || indexHighA > 255) { + // the PDF spec requires indexHigh to be in [0,255] -- allowing + // values larger than 255 creates a security hole: if nComps * + // indexHigh is greater than 2^31, the loop below may overwrite + // past the end of the array + error(-1, "Bad Indexed color space (invalid indexHigh value)"); + delete baseA; + goto err2; + } obj1.free(); cs = new GfxIndexedColorSpace(baseA, indexHighA); arr->get(3, &obj1);

4 3

Re: pdftex 20021209 broken
by Martin Schroeder 19 Dec '02

19 Dec '02

On 2002-12-13 04:40:15 +0100, Staszek Wawrykiewicz wrote: > >> Error: pdftex (file pic.pdf): xpdf: reading PDF image failed > >> ==> Fatal error occurred, the output PDF file is not finished! > > TE> Yes, fixed in "pdfTeX, Version 3.14159-1.10a-RC1 (Web2C 7.3.11)" > TE> (as contained in 20021210 pretest. Anyway, thanks for reporting. > > Thanks. I recompiled it immediatelly. BTW, teTeX-src-beta.tar.gz is not > properly linked to those from 20021209. > Since I'm not on pdftex mailing list, I Cc some notes to other people. > > This is pdfTeX, Version 3.14159-1.10a-RC1 (Web2C 7.3.11) > \write18 enabled. > (./samplepdf.tex{/usr/local/teTeX/texmf/pdftex/config/pdftex.cfg} > (/usr/local/teTeX/texmf/pdftex/plain/misc/pdfcolor.tex){/usr/local/teTeX/texmf/ > dvips/config/pdftex.map} [1<<obj.dat>><<obj.dat>><<obj.dat>>] [2 <./pic.pdf> <. > /pic.png> <./pic.pdfSegmentation fault Staszek, thanks for the bug report. The example can be simplified to \pdfximage {pic.pdf}\pdfrefximage \pdflastximage \pdfximage {pic.pdf}\pdfrefximage \pdflastximage \bye with the same effect. :-( [...] > I found also that we have somehow different samplepdf.tex on TL7 and in > teTeX-beta. Since I see this file as a good example for testing pdftex > primitives (and also educational!), I can do all changes taking the best > from both. But perhaps it is already done somewhere? Please let me know. > > It is good time for cleaning up the contents of texmf/doc/pdftex/, e.g., > removing obsolete intermediary files in TL and teTeX. Yes. Sadly samplepdf is currently not maintained AFAIK. Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

4 9

Re: pdf inclusion and max open fd
by Martin Schroeder 17 Dec '02

17 Dec '02

On 2002-07-26 11:43:40 +0200, Fabrice Popineau wrote: > The problem is in web2c/pdftexdir/pdftoepdf.cc : > > // Called when an image has been written and it's resources in > // image_tab are freed. We cannot deallocate the PdfDocument yet, as > // future pages of the same document may be embedded. As an > // optimization, we do delete it if it's a one-page document. > void epdf_delete() > { > > // Akira Kakuto has suggested to make epdf_delete empty, so > #if 0 > PdfDocument *pdf_doc = (PdfDocument *) epdf_doc; > xref = pdf_doc->xref; > if (pdf_doc->doc->getCatalog()->getNumPages() == 1) > delete_document(pdf_doc); > #endif > } > > This is really weird, because that means files are never closed during > the compilation, but only when the program exits because the > destructors for PDFDoc objects are called. Restoring the deletion here > will make things work as long as we are using 1 page pdf > documents. But I think that the way included pdf documents are handled > should be reworked, perhaps following Hans suggestion to add a command > to explicitly close the document. Shall (and can) we do this for 1.10a or will we postpone it till 1.11a? Adding a closing command (like \pdfximageclose) makes sense to me. Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

1 0

xpdf 2.01
by Martin Schroeder 09 Dec '02

09 Dec '02

I've integrated it. Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

1 0