April 2008 - ntg-pdftex - NTG Mailing Lists

[pdftex-Patches][945] experimental support for tagged PDF
by pdftex-patches＠sarovar.org 30 Apr '08

30 Apr '08

Patches item #945, was opened at 2008-04-27 10:19 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hans Hagen (hagen) Summary: experimental support for tagged PDF Resolution: None Group: v1.40.0 Category: Primitives Initial Comment: This is a patch to experiment with tagged PDF. The example passes PDF/A-1a check in Acrobat Pro 8. Most of the work is done manually at macro level; we want to provide only unavoidable low-level support and new primitives. This is in very alpha stage and is intended for those who are willing to experiment with tagged PDF: you need to know about tagged PDF at low level (chapter 10 from PDF specification), about the \pdfobj primitive of pdftex and some macro programing experience. Please don't try it yet if you want an out-of-the-box solution, since it's not clear yet if it is possible at all. - apply the patch: - unpack pdftex-1.40.4.tar.bz2 - cd /path/to/pdftex.1.40.4 - patch -p1 </path/to/tagged-pdf-1.diff - build pdftex & generate new format - run "pdflatex -shell-escape f.tex" to compile the test file ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-04-30 10:18 Message: added a little less trivial example f2.tex which closely mimics example 10.15 from pdf1.7 spec. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=945&group_id=106

1 0

[pdftex-Feature Requests][429] Generate Tagged PDF
by pdftex-featurerequests＠sarovar.org 27 Apr '08

27 Apr '08

Feature Requests item #429, was opened at 2005-09-11 22:37 Status: Open Priority: 2 Submitted By: Timothy O'Brien (oberon101) Assigned to: Martin Schröder (oneiros) Summary: Generate Tagged PDF Resolution: None Group: None Category: None Initial Comment: Adobe Reader has a'reflow' feature that allows visually impaired users to zoom into properly formatted documents and read them without having to move the viewable area back and forth across the page. PDFs made in MikteX eith pdfte are not properly formatted and reflow without interword spacing, redering them unreadable. I contacted the MikteX people and they referred me here. I beleive Scientific Word also uses pdftex with the same result. Any chance this could be fixed? ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-04-27 10:22 Message: here is an attempt: http://sarovar.org/tracker/index.php?func=detail&aid=945&group_id=106&atid=… ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-05-16 11:49 Message: Logged In: NO " The main problem with reflowing is not the missing tags but that pdftex writes interword spaces as a kern (since there is no "space" in TeX, of course). " No, the main problem is that Adobe Reader dropped recognition of "words" based on *spacing* and resorted to the the simplistic approach to use *spaces* instead. This is simply ignorance of Adobe about TeX. Instead of whining about this one can do something for a practical cure: add dummy spaces at the end of every word of zero width which consist of a *space* and a kern -\wd(space). space could come from any font producing explicit spaces in the output (e.g. cmtt). It is most easily done with VF's. As far as I remember a real implementation is already there in Vtex (with some option). " non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used " i) when generating PS-code and distilling via Adobe Distiller there should be no problem to take care of pdfmarks created by classes & packages... ii) I consider the major problem is page building and page dependency of marked contents. It is just like the difficulty to get consistent color in TeX: one can consider color as sort of a "tag". E.g. a marked TeX paragraph is broken accross pages with (tagged) headers and the structure should in general kept linked also under the condition of reordered pages. I suggest first to define what functionality is required at the side of the PDF-Reader (text extraction, save as XML or audio output via screen reader). The packages should then be able to save Latex macro structure as pdfmarks for pdf tags as a prerequisite. Support of pagebreaking of tagged objects will require some assistance from pdftex like linebreaking of weblinks. HS ---------------------------------------------------------------------- Comment By: Robert (schlcht) Date: 2006-05-06 15:20 Message: Logged In: YES user_id=2217 The main problem with reflowing is not the missing tags but that pdftex writes interword spaces as a kern (since there is no "space" in TeX, of course). A rather simple but effective way would be to write the interword spaces in a different font (e.g. non-embedded Times-Roman), and then compensate for the difference between Times's width of space and the width of the glue calculated by TeX. (At least, this is what Distiller does, if you select "Advanced -> Accessibility -> Add Tags to Document".) So that (This)-419(is)-420(an)-419(example) will be turned into: /T1_0 1 Tf (This)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 2.369 0 Td (is)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 1.092 0 Td (an)Tj /T1_1 1 Tf ( )Tj /T1_0 1 Tf 1.475 0 Td (example)Tj where T1_0 is cmr10 and T1_1 is Times-Roman. This would be already a major enhancement with respect to accessibility without any packages being required. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-04-14 11:33 Message: Logged In: NO Maybe a first version can use a very low-level solution, just with a single tagging primitive; there is such a command already (I think it is called pdfliteral) . And the tree can come later. So one could start with little work, assuming one knows tagging. CS ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-04-14 11:12 Message: Logged In: YES user_id=421 I'm changing the summary. Yes, we are aware that tagged pdf is an often requested feature, but implementing it would be non-trivial: - first pdfTeX would have to be extended with primites for a structure tree (and classes and packages would have to use these primitives) - then primitives for tagging the content are needed and must be used ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-11-04 19:58 Message: Logged In: NO I would volonteer to test the feature. I am writing a rather long pdf produced with pdftex that is downloadable for free ( http://www.motionmountain.net ) and readers regularly ask why it cannot be read aloud. Pdftex probably would only need to be extended with a single command - something like \writetaghere{tagtype} - and all the rest could be done by extensions to the latex cls and sty files. CS ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=429&group_id=106

1 0

[pdftex-Patches][945] experimental support for tagged PDF
by pdftex-patches＠sarovar.org 27 Apr '08

27 Apr '08

Patches item #945, was opened at 2008-04-27 10:19 Status: Open Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: Hans Hagen (hagen) Summary: experimental support for tagged PDF Resolution: None Group: v1.40.0 Category: Primitives Initial Comment: This is a patch to experiment with tagged PDF. The example passes PDF/A-1a check in Acrobat Pro 8. Most of the work is done manually at macro level; we want to provide only unavoidable low-level support and new primitives. This is in very alpha stage and is intended for those who are willing to experiment with tagged PDF: you need to know about tagged PDF at low level (chapter 10 from PDF specification), about the \pdfobj primitive of pdftex and some macro programing experience. Please don't try it yet if you want an out-of-the-box solution, since it's not clear yet if it is possible at all. - apply the patch: - unpack pdftex-1.40.4.tar.bz2 - cd /path/to/pdftex.1.40.4 - patch -p1 </path/to/tagged-pdf-1.diff - build pdftex & generate new format - run "pdflatex -shell-escape f.tex" to compile the test file ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=945&group_id=106

1 0

Re : PDF images : any limit to their number in PdfTeX (Win-32, TeX Live 2007)
by Philip TAYLOR (Ret'd) 26 Apr '08

26 Apr '08

My sincere thanks to all who responded; I have reverted to an earlier version which did not use \halign, and I can once again process all images. I think that in retrospect, expecting PdfTeX to buffer all 4500 images while it computed the widths of the columns of an \halign was probably expecting too much. ** Phil.

1 0

PDF images : any limit to their number in PdfTeX (Win-32, TeX Live 2007)
by Philip TAYLOR (Ret'd) 25 Apr '08

25 Apr '08

I am endeavouring to typeset a book which will include between four and five thousand PDF images (included using \includeimage from package "Graphicx"); PdfTeX (Win-32, TeX Live 2007) is bombing out with no error message, and I am concerned it may be hitting some limit. Is there any known limit, and if not, does four to five thousand seem reasonable ? I should add that each of these images forms a part of one row of an \halign ... Philip TAYLOR

3 3

Re: [NTG-pdftex] PDF images : any limit to their number in PdfTeX (Win-32, TeX Live 2007)
by Akira Kakuto 25 Apr '08

25 Apr '08

... ... > Is there any known limit, and if not, > does four to five thousand seem reasonable ? I don't remember the limit on the number of open files in pdfTeX-w32 in TL-2007. The limit will be 2048, including stdin etc., in TL-2008. The total file size can be over 2GB in TL-2008. Best, Akira

1 0

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

22 Apr '08

Bugs item #939, was opened at 2008-04-19 23:42 Status: Open Priority: 3 Submitted By: Hartmut Henkel (hhenkel) >Assigned to: Hartmut Henkel (hhenkel) Summary: \pdfximagebbox wrong for PDF files with /Rotate != 0 >Resolution: Accepted 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. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2008-04-22 10:35 Message: Hrm. Is \pdfximagebbox actually used? And if it's used, is it enough when /Rotate is present or do we need a way to enquire about /Rotate? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=939&group_id=106

1 0

[pdftex-Bugs][941] pdf inclusion broken on ppc-linux
by pdftex-bugs＠sarovar.org 22 Apr '08

22 Apr '08

Bugs item #941, was opened at 2008-04-22 10:32 Status: Open Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: pdf inclusion broken on ppc-linux Resolution: None Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: pdf inclusion is currently broken on ppc-linux (see http://www.ntg.nl/pipermail/ntg-pdftex/2008-April/003500.html ). ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=941&group_id=106

1 0

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

22 Apr '08

Bugs item #940, was opened at 2008-04-21 11:26 >Status: Closed >Priority: 1 Submitted By: Anand R (anandraichur) Assigned to: Nobody (None) Summary: PDflatex draws large call graphs over the page >Resolution: Invalid 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. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2008-04-22 10:31 Message: So either scale down the image or increase the page size, e.g. with the geometry page. But this is NOT a pdfTeX bug. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=940&group_id=106

1 0

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