- ntg-pdftex - NTG Mailing Lists

LFS on powerpc-apple-darwin
by Martin Schröder 21 Apr '08

21 Apr '08

Hi, I need help with Large File Support on powerpc-apple-darwin; it's broken in pdftex-stable and -trunk. With a binary from -stable pdf inclusion is currently broken on powerpc-apple-darwin 8.11; when trying to include any pdf (I'm testing with the output of sample2e.tex) I get this error: "No space left on device" and sure, when I fire up gdb it shows this: ------------------- (gdb) bt #0 0x90014ba8 in write () #1 0x90015cbc in _swrite () #2 0x900055f8 in __sflush () #3 0x9006abe0 in fseeko () #4 0x001c9aac in xfseeko (f=0xa000dbe4, offset=64656437686498, wherefrom=0, filename=0x232ae80 "test-inc") at ../../../src/texk/kpathsea/xfseeko.c:28 #5 0x000cfe80 in writestreamlength (length=3909, offset=64656437682547) at ../../../../src/texk/web2c/pdftexdir/utils.c:412 #6 0x00061a88 in pdfendstream () at pdftex1.c:8395 ------------------- The offset is a bit large.:-{ This is regardless of --disable-largefile. When compiling -stable I get these nice warnings: ------------------- gcc -DHAVE_CONFIG_H -I. -I../../../src/texk/web2c -I.. -I../../../src/texk/web2c/.. -I../../libs/obsdcompat -I ../../libs/obsdcompat/.. -I../../../src/texk/web2c/../../libs/obsdcompat -I../../../src/texk/web2c/../../libs/ob sdcompat/.. -g3 -Wall -Wno-write-strings -std=c99 -c pdftex0.c -o pdftex0.o In file included from ../../../src/texk/web2c/../../libs/obsdcompat/includes.h:27, from ../../../src/texk/web2c/../../libs/obsdcompat/openbsd-compat.h:37, from ../../../src/texk/web2c/pdftexdir/ptexlib.h:41, from ../../../src/texk/web2c/pdftexdir/pdftex.h:67, from pdftexcoerce.h:1605, from pdftexd.h:789, from pdftex0.c:2: ../../libs/obsdcompat/../obsdcompat/config.h:219:1: warning: "WORDS_BIGENDIAN" redefined In file included from pdftexd.h:11, from pdftex0.c:2: ../../../src/texk/web2c/texmfmp.h:31:1: warning: this is the location of the previous definition ------------------- And sure enough obsdcompat/config.h has this: ------------------- /* Define to 1 if your processor stores words with the most significant byte first (like Motorola and SPARC, unlike Intel and VAX). */ #define WORDS_BIGENDIAN 1 ------------------- while texmfmp.h has this: /* If we have these macros, use them, as they provide a better guide to the endianess when cross-compiling. */ ------------------- #if defined (BYTE_ORDER) && defined (BIG_ENDIAN) && defined (LITTLE_ENDIAN) #ifdef WORDS_BIGENDIAN #undef WORDS_BIGENDIAN #endif #if BYTE_ORDER == BIG_ENDIAN #define WORDS_BIGENDIAN #endif #endif /* More of the same, but now NeXT-specific. */ #ifdef NeXT #ifdef WORDS_BIGENDIAN #undef WORDS_BIGENDIAN #endif #ifdef __BIG_ENDIAN__ #define WORDS_BIGENDIAN #endif #endif ------------------- Might this be the reason? Best Martin

1 1

[pdftex-Bugs][940] PDflatex draws large call graphs over the page
by pdftex-bugs＠sarovar.org 21 Apr '08

21 Apr '08

Bugs item #940, was opened at 2008-04-21 09:26 Status: Open Priority: 3 Submitted By: Anand R (anandraichur) Assigned to: Nobody (None) Summary: PDflatex draws large call graphs over the page Resolution: None Group: v1.40.6 Category: PDF inclusion Initial Comment: iam using pdflatex version 1.40.7 with miktex 2.7 , while converting the large callgrapha to PDF the graph is drawn over the page. The size of the PDF is (7.61*32.44inches) the graphn is getting truncated in the final output to (8.27*11.69inches) only the first 11.69 inches of the graph is visible. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=940&group_id=106

1 0

[pdftex-Bugs][939] \pdfximagebbox wrong for PDF files with /Rotate != 0
by pdftex-bugs＠sarovar.org 19 Apr '08

19 Apr '08

Bugs item #939, was opened at 2008-04-19 23:42 Status: Open Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: \pdfximagebbox wrong for PDF files with /Rotate != 0 Resolution: None Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: The primitive \pdfximagebbox gives a wrong boundingbox info for PDF files that contain a /Rotate key with value 90 or 270 [degrees]. Reason is that in pdftoepdf.cc the values epdf_height and epdf_width are swapped in 90 and 270 degree cases (but the epdf_orig_x and epdf_orig_y are not swapped, which makes it even more inconsistent). The proposal is that \pdfximagebbox should always deliver the unchanged original values for the actually used boundingbox (e. g. "artbox", "cropbox"...), as read from the appropriate /...Box[] array in the embedded PDF file. The epdf_height and epdf_width values should _not_ be swapped for \pdfximagebbox. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=939&group_id=106

1 0

[pdftex-Bugs][936] PDF image vpos wrong when PDF origin != 0
by pdftex-bugs＠sarovar.org 14 Apr '08

14 Apr '08

Bugs item #936, was opened at 2008-04-09 00:40 >Status: Closed Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: PDF image vpos wrong when PDF origin != 0 >Resolution: Fixed Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: When a PDF image is embedded, and its /MediaBox contains a negative lly value, and if a depth != 0 is assigned with \pdfximage, the PDF image will be placed wrong vertically. the attached file cow1.pdf has a tweaked /MediaBox to force this effect. if this is a bug, it seems to be a rather longstanding one. see trivial patch to cure this. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2008-04-14 11:08 Message: Fixed ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-04-09 22:23 Message: see PDF output for unpatched and patched pdftex in bug-936.zip. The bug appears e. g., if one uses \pdfximage with a non-zero depth parameter (pos. or neg.) together with option "artbox". It happens only very seldom for "mediabox" (default), as most MediaBoxes have 0 0 as their lower left corner (i guess), and not many people are using \pdfximage with a depth parameter anyway. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-04-09 01:03 Message: Please attach a tex input file demonstrating the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=936&group_id=106

1 0

[pdftex-Bugs][936] PDF image vpos wrong when PDF origin != 0
by pdftex-bugs＠sarovar.org 10 Apr '08

10 Apr '08

Bugs item #936, was opened at 2008-04-09 00:40 Status: Open Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: PDF image vpos wrong when PDF origin != 0 >Resolution: Accepted Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: When a PDF image is embedded, and its /MediaBox contains a negative lly value, and if a depth != 0 is assigned with \pdfximage, the PDF image will be placed wrong vertically. the attached file cow1.pdf has a tweaked /MediaBox to force this effect. if this is a bug, it seems to be a rather longstanding one. see trivial patch to cure this. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2008-04-09 22:23 Message: see PDF output for unpatched and patched pdftex in bug-936.zip. The bug appears e. g., if one uses \pdfximage with a non-zero depth parameter (pos. or neg.) together with option "artbox". It happens only very seldom for "mediabox" (default), as most MediaBoxes have 0 0 as their lower left corner (i guess), and not many people are using \pdfximage with a depth parameter anyway. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-04-09 01:03 Message: Please attach a tex input file demonstrating the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=936&group_id=106

1 0

[pdftex-Bugs][936] PDF image vpos wrong when PDF origin != 0
by pdftex-bugs＠sarovar.org 09 Apr '08

09 Apr '08

Bugs item #936, was opened at 2008-04-09 00:40 Status: Open Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Martin Schröder (oneiros) Summary: PDF image vpos wrong when PDF origin != 0 Resolution: None Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: When a PDF image is embedded, and its /MediaBox contains a negative lly value, and if a depth != 0 is assigned with \pdfximage, the PDF image will be placed wrong vertically. the attached file cow1.pdf has a tweaked /MediaBox to force this effect. if this is a bug, it seems to be a rather longstanding one. see trivial patch to cure this. ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2008-04-09 22:23 Message: see PDF output for unpatched and patched pdftex in bug-936.zip. The bug appears e. g., if one uses \pdfximage with a non-zero depth parameter (pos. or neg.) together with option "artbox". It happens only very seldom for "mediabox" (default), as most MediaBoxes have 0 0 as their lower left corner (i guess), and not many people are using \pdfximage with a depth parameter anyway. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-04-09 01:03 Message: Please attach a tex input file demonstrating the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=936&group_id=106

1 0

[pdftex-Bugs][936] PDF image vpos wrong when PDF origin != 0
by pdftex-bugs＠sarovar.org 09 Apr '08

09 Apr '08

Bugs item #936, was opened at 2008-04-09 00:40 Status: Open Priority: 3 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: Martin Schröder (oneiros) Summary: PDF image vpos wrong when PDF origin != 0 Resolution: None Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: When a PDF image is embedded, and its /MediaBox contains a negative lly value, and if a depth != 0 is assigned with \pdfximage, the PDF image will be placed wrong vertically. the attached file cow1.pdf has a tweaked /MediaBox to force this effect. if this is a bug, it seems to be a rather longstanding one. see trivial patch to cure this. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2008-04-09 01:03 Message: Please attach a tex input file demonstrating the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=936&group_id=106

1 0

[pdftex-Bugs][936] PDF image vpos wrong when PDF origin != 0
by pdftex-bugs＠sarovar.org 09 Apr '08

09 Apr '08

Bugs item #936, was opened at 2008-04-09 00:40 Status: Open Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: PDF image vpos wrong when PDF origin != 0 Resolution: None Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: When a PDF image is embedded, and its /MediaBox contains a negative lly value, and if a depth != 0 is assigned with \pdfximage, the PDF image will be placed wrong vertically. the attached file cow1.pdf has a tweaked /MediaBox to force this effect. if this is a bug, it seems to be a rather longstanding one. see trivial patch to cure this. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=936&group_id=106

1 0

[pdftex-Feature Requests][662] avoid creating "fixed destination"
by pdftex-featurerequests＠sarovar.org 26 Mar '08

26 Mar '08

Feature Requests item #662, was opened at 2006-10-20 13:57 >Status: Closed Priority: 3 Submitted By: Ulrich Diez (ulrichdiez) Assigned to: The Thanh Han (hanthethanh) >Summary: avoid creating "fixed destination" >Resolution: Rejected Group: v1.50 Category: None Initial Comment: When referencing a non-existing destination, you get this warning: ! pdfTeX warning (dest): name{<something>} has been referenced but does not exist, replaced by a fixed one I always like the warning about non-existing destinations, but sometimes I'd prefer pdfTeX not to take action besides issuing a warning-message/I'd prefer pdfTeX not to create a "fixed" destination. E.g., when creating several separate pdf-files with pdfTeX (for later merging them together by means of external software like "pdftk" or "pdfcat") whereby the named destination is not known/available when compiling file A but is available/provided in file B so that in the result from merging these files, everything will be fine. Does it make sense/is it possible to implement some mechanism for forking if creation of fixed destination shall be avoided or not? (Either a new token/primitive similar to \globaldefs which can be used within TeX source or some command- line-option which can be specified at the command-line when running pdfTeX ?) Sincerely Ulrich ---------------------------------------------------------------------- Comment By: Ulrich Diez (ulrichdiez) Date: 2008-03-25 11:24 Message: This feature-request of mine is obsolete. By using \pdfliteral and \special you can easily create links to non-existing destinations which will not get replaced by "a fixed one" so that after pdf-concatenation links will work. I apologize for having send this feature-request. Sincerely Ulrich ---------------------------------------------------------------------- Comment By: Ulrich Diez (ulrichdiez) Date: 2008-03-25 11:23 Message: This feature-request of mine is obsolete. By using \pdfliteral and \special you can easily create links to non-existing destinations which will not get replaced by "a fixed one" so that after pdf-concatenation links will work. I apologize for having send this feature-request. Sincerely Ulrich ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=662&group_id=106

1 0

[pdftex-Bugs][935] The primitive \pdfstrcmp is not documented in the manuals
by pdftex-bugs＠sarovar.org 25 Mar '08

25 Mar '08

Bugs item #935, was opened at 2008-03-25 10:40 Status: Open Priority: 3 Submitted By: Ulrich Diez (ulrichdiez) Assigned to: Nobody (None) Summary: The primitive \pdfstrcmp is not documented in the manuals Resolution: None Group: None Category: None Initial Comment: The primitive \pdfstrcmp is documented neither in pdftex-syntax.txt, nor in "The pdfTeX manual (a4/letter/screen). (http://sarovar.org/docman/index.php?group_id=106&selected_doc_group_id=307&…) At comp.text.tex I was advised to send a bug-report. Ulrich ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=935&group_id=106

1 0