- hz problems. Anything else? Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
Martin Schröder wrote:
- hz problems.
not that i know of Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 2004-07-01 16:48:34 +0200, Hans Hagen wrote:
Martin Schröder wrote:
- hz problems. not that i know of
http://www.ntg.nl/pipermail/ntg-pdftex/2004-June/000576.html Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
Martin Schröder wrote:
On 2004-07-01 16:48:34 +0200, Hans Hagen wrote:
Martin Schröder wrote:
- hz problems.
not that i know of
eh .. the hz problem si still there; there are *no other problems* that i know of -)
Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Thu, Jul 01, 2004 at 04:37:00PM +0200, Martin Schröder wrote:
Anything else?
There was a segmentation fault problem with large images,
discussed on de.comp.text.tex, that was AFAIK never reported
on the *pdftex mailing lists.
Message-ID: c8ccnp$fvo$1@n.ruf.uni-freiburg.de
Yours sincerely
Heiko
On 2004-07-01 17:17:55 +0200, Heiko Oberdiek wrote:
There was a segmentation fault problem with large images, discussed on de.comp.text.tex, that was AFAIK never reported on the *pdftex mailing lists.
Message-ID: c8ccnp$fvo$1@n.ruf.uni-freiburg.de
Thanks. The file is at http://www.ndh.net/home/mauz/majox.de/newsgroup/compile-ablauf.png Hartmut? Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On Thu, 1 Jul 2004, Martin Schröder wrote:
Thanks. The file is at http://www.ndh.net/home/mauz/majox.de/newsgroup/compile-ablauf.png
Hartmut?
with rc4 i get ./compile-ablauf.pngSpeicherzugriffsfehler will check... Regards, Hartmut
seems the pdf_buf is overrun by the very long re-zipped image lines. By this weird pointer garblings happen (valgrind). E. g. increasing pdf_buf_size from 16384 to 26384 makes it run (but is not yet the general solution). Regards, Hartmut
W3C says that the deflate (LZ77) window for PNG may not be larger than
32768 bytes, which still isn't large. Perhaps change pdf_buf_size to 64K?
On Thu, 1 Jul 2004 21:53:57 +0200 (CEST)
Hartmut Henkel
seems the pdf_buf is overrun by the very long re-zipped image lines. By this weird pointer garblings happen (valgrind). E. g. increasing pdf_buf_size from 16384 to 26384 makes it run (but is not yet the general solution).
Regards, Hartmut _______________________________________________ ntg-pdftex mailing list ntg-pdftex@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-pdftex
Hi, Just to let you know: I cannot get the HEAD to compile without manually adding a "-i" option to the make call in the Build script. "make" bombs at: gcc -g -O2 -o texindex texindex.o ../lib/libtxi.a make[4]: *** No rule to make target `../../../../../TeX/utils/texinfo/doc/version.texi', needed by `texinfo.cat'. Stop. make[4]: Leaving directory `/home/taco/perforce/Build/source.development/Work/TeX/utils/texinfo/util' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/taco/perforce/Build/source.development/Work/TeX/utils/texinfo' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/taco/perforce/Build/source.development/Work/TeX/utils/texinfo' make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/taco/perforce/Build/source.development/Work/TeX' And later, the lcdf-typetools don't compile (not updated for automake-1.8 yet?). I get loads and loads of these "underquoted" warnings: making all in utils/lcdf-typetools make[2]: Entering directory `/home/taco/perforce/Build/source.development/Work/TeX/utils/lcdf-typetools' cd ../../../../TeX/utils/lcdf-typetools && /bin/sh /home/taco/perforce/Build/source.development/TeX/utils/lcdf-typetools/missing --run aclocal-1.8 /usr/share/aclocal/vorbis.m4:9: warning: underquoted definition of XIPH_PATH_VORBIS run info '(automake1.8)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal /usr/share/aclocal/ogg.m4:8: warning: underquoted definition of XIPH_PATH_OGG -- groeten, Taco
On 2004-07-05 12:20:44 +0200, Taco Hoekwater wrote:
Just to let you know: I cannot get the HEAD to compile without manually adding a "-i" option to the make call in the Build script.
Taco, this properly belongs to the TeXlive list. I can happily compile the pdftex part of texlive. Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On Thu, 1 Jul 2004, Martin Schröder wrote:
Thanks. The file is at http://www.ndh.net/home/mauz/majox.de/newsgroup/compile-ablauf.png
The pdf_buf (pdf_buf_size = 16384 bytes) is overrun by the long lines (18051 pixels, R + G + B) in writepng(). There is always the pdfroom() macro called, but why then isn't the overrun detected? The reason is in ptexmac.h, whose pdfroom(n) macro is used (and not the pdf_room(#) macro from pdftex.ch!). Funnily in ptexmac.h these macro lines if (pdfbufsize - n < 0) \ pdftex_fail("PDF output buffer overflowed"); \ do never flag any overflow, but these if (pdfbufsize < n) \ pdftex_fail("PDF output buffer overflowed"); \ work ok, e. g. an overflow error is generated with the given image. Macro weirdness, something with signed/unsigned? So this would be a change to ptexmac.h. Similar subtraction is done also in pdf_room(#) in pdftex.ch, so maybe one should change this also, to be safe. Then for handling such big images one could increase pdf_buf_size to maybe 25000. Instead here is a patch that cuts arbitrary long image lines into snipplets always fitting into pdf_buf_size. Tested with the above image. Regards, Hartmut --- writepng.c.orig Mon Jul 1 18:07:00 2002 +++ writepng.c Thu Jul 1 23:14:33 2004 @@ -67,7 +67,7 @@ void write_png(integer img) { - int i, j; + int i, j, k, l; integer palette_objnum = 0; png_bytep row, *rows; pdf_puts("/Type /XObject\n/Subtype /Image\n"); @@ -100,9 +100,14 @@ row = xtalloc(png_info(img)->rowbytes, png_byte); for (i = 0; i < (int)png_info(img)->height; i++) { png_read_row(png_ptr(img), row, NULL); - pdfroom(png_info(img)->rowbytes); - for (j = 0; j < (int)png_info(img)->rowbytes; j++) - pdfbuf[pdfptr++] = row[j]; + k = png_info(img)->rowbytes; + while(k > 0) { + l = (k > pdfbufsize)? pdfbufsize : k; + pdfroom(l); + for (j = 0; j < l; j++) + pdfbuf[pdfptr++] = row[j]; + k -= l; + } } xfree(row); } @@ -115,9 +120,14 @@ png_read_image(png_ptr(img), rows); for (i = 0; i < (int)png_info(img)->height; i++) { row = rows[i]; - pdfroom(png_info(img)->rowbytes); - for (j = 0; j < (int)png_info(img)->rowbytes; j++) - pdfbuf[pdfptr++] = *row++; + k = png_info(img)->rowbytes; + while(k > 0) { + l = (k > pdfbufsize)? pdfbufsize : k; + pdfroom(l); + for (j = 0; j < l; j++) + pdfbuf[pdfptr++] = *row++; + k -= l; + } xfree(rows[i]); } xfree(rows);
http://www.ndh.net/home/mauz/majox.de/newsgroup/compile-ablauf.png
writepng.c patch was wrong, corrected below, sorry. Regards, Hartmut --- writepng.c.orig Mon Jul 1 18:07:00 2002 +++ writepng.c Fri Jul 2 01:58:59 2004 @@ -67,9 +67,9 @@ void write_png(integer img) { - int i, j; + int i, j, k, l; integer palette_objnum = 0; - png_bytep row, *rows; + png_bytep row, r, *rows; pdf_puts("/Type /XObject\n/Subtype /Image\n"); pdf_printf("/Width %i\n/Height %i\n/BitsPerComponent %i\n", (int)png_info(img)->width, @@ -100,9 +100,15 @@ row = xtalloc(png_info(img)->rowbytes, png_byte); for (i = 0; i < (int)png_info(img)->height; i++) { png_read_row(png_ptr(img), row, NULL); - pdfroom(png_info(img)->rowbytes); - for (j = 0; j < (int)png_info(img)->rowbytes; j++) - pdfbuf[pdfptr++] = row[j]; + r = row; + k = png_info(img)->rowbytes; + while(k > 0) { + l = (k > pdfbufsize)? pdfbufsize : k; + pdfroom(l); + for (j = 0; j < l; j++) + pdfbuf[pdfptr++] = *r++; + k -= l; + } } xfree(row); } @@ -115,9 +121,14 @@ png_read_image(png_ptr(img), rows); for (i = 0; i < (int)png_info(img)->height; i++) { row = rows[i]; - pdfroom(png_info(img)->rowbytes); - for (j = 0; j < (int)png_info(img)->rowbytes; j++) - pdfbuf[pdfptr++] = *row++; + k = png_info(img)->rowbytes; + while(k > 0) { + l = (k > pdfbufsize)? pdfbufsize : k; + pdfroom(l); + for (j = 0; j < l; j++) + pdfbuf[pdfptr++] = *row++; + k -= l; + } xfree(rows[i]); } xfree(rows);
On 2004-07-02 02:09:43 +0200, Hartmut Henkel wrote:
http://www.ndh.net/home/mauz/majox.de/newsgroup/compile-ablauf.png
writepng.c patch was wrong, corrected below, sorry.
It's in (#5440). Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On 2004-07-01 16:37:00 +0200, Martin Schröder wrote:
- hz problems.
Anything else?
Seems not. This leaves us with the NEWS file. Could someone (Hartmut?) please elaborate a bit on these items: ------------------ - support embedding base fonts. - fixed a few problems with handling fonts in included pdf. - support for auto font expansion -- expanded TFM's are not required - support for base font inclusion as suggested by Hartmut ------------------ These could be a bit more verbose. :-) And is anything missing there? Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On Thu, 8 Jul 2004, Martin Schröder wrote:
Could someone (Hartmut?) please elaborate a bit on these items: ------------------ - support embedding base fonts. - fixed a few problems with handling fonts in included pdf. - support for auto font expansion -- expanded TFM's are not required - support for base font inclusion as suggested by Hartmut ------------------
well, vaguely... - support for standard font embedding The 14 Type 1 "standard fonts" (Times, Helvetica...) are now more or less handled like any other Type 1 font. The embedding of these standard fonts is not any more blocked, if their true FontName is given as the 2nd field in a pdftex.map line. If a FontName out of the standard fonts is listed there, but the corresponding font file can't be found, a warning will be issued, and an unembedded version of the standard font will be used. It's then up to the PDF viewer application to display the text by its own standard font version. If a font with FontName _not_ belonging to the "standard fonts" is given in pdftex.map, and the corresponding font file can't be found, a warning will be issued, and the font will be replaced by some default font (which will normally be visually distracting). Checks of fontfile existence will be done at the time when the font is required. - support embedded standard fonts in included PDF files When a PDF file with embedded fonts is to be included, its FontName entries will be matched against the FontName fields (2nd field) in the pdftex.map file. If a match is found, the embedded font will be replaced by a font managed by pdftex. This normally reduces the PDF file size, when several included PDF files contain glyphs from the same font. The font replacement works now also for Type 1 standard fonts embedded into the included PDF files. If the pdftex.map file contains more than one line with the same matching FontName field, the best suited replacement font will be selected, using hierarchical criteria of whether a font is already in use (best case), or whether the TFM file is existing or not. Unembedded fonts coming with included PDF files are generally left untouched. - fixed a few problems with handling fonts in included pdf. ? - support for auto font expansion -- expanded TFM's are not required ? Needs some example runs to see how it now works. Also what's now with these obsolete expanded font files like font+15.tfm or MM instances like font-30.pfb: Do they hurt? Can they still be used? All this is cleaned up, or? Regards, Hartmut
On 2004-07-09 01:53:10 +0200, Hartmut Henkel wrote:
On Thu, 8 Jul 2004, Martin Schröder wrote:
Could someone (Hartmut?) please elaborate a bit on these items: ------------------ - support embedding base fonts. - fixed a few problems with handling fonts in included pdf. - support for auto font expansion -- expanded TFM's are not required - support for base font inclusion as suggested by Hartmut ------------------
well, vaguely...
Have a look at the new NEWS in p4. It's a bit long. :-{ Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
- fixed a few problems with handling fonts in included pdf.
?
the most prominent change was the way pdftex handles tfm of fonts found in included pdf's. Thanks to Harmut's work on using the avl library, things are much cleaner now.
- support for auto font expansion -- expanded TFM's are not required
?
Needs some example runs to see how it now works. Also what's now with these obsolete expanded font files like font+15.tfm or MM instances like font-30.pfb: Do they hurt? Can they still be used? All this is cleaned up, or?
if auto expansion is not used, then pdftex behaviour doesn't change. The only thing that is gone is the font expansion factor, which proved to cause a lot of troubles and didn't bring any benefit. My intention was to use this parameter to simulate font expansion by letterspacing. In short, auto font expansion is just like `normal' font expansion, except that a few things are done automatically ;) Thanh
participants (6)
-
Hans Hagen -
Hartmut Henkel -
Heiko Oberdiek -
Martin Schröder -
Taco Hoekwater -
The Thanh Han