- ntg-pdftex - NTG Mailing Lists

Re: pdftosrc man page (fwd)
by Hartmut Henkel 03 Nov '05

03 Nov '05

...seems one has to subscribe to the list to post there ---------- Forwarded message ---------- Date: Thu, 03 Nov 2005 13:51:31 +0100 From: Frank Küster <frank(a)kuesterei.ch> To: Hartmut Henkel <hartmut_henkel(a)gmx.de> Cc: ntg-pdftex(a)ntg.nl, Hilmar Preusse <hille42(a)web.de> Subject: Re: pdftosrc man page Hartmut Henkel <hartmut_henkel(a)gmx.de> wrote: > i've put a sketchy man page for Thanh's nice pdftosrc utility at > > http://www.circuitwizard.de/misc/pdftosrc.1.gz > > Please have a look whether one can live with it for now. Is this based on Hilmars work that we sent to the list earlier, or is it written from scratch? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer

1 0

pdftosrc man page
by Hartmut Henkel 03 Nov '05

03 Nov '05

i've put a sketchy man page for Thanh's nice pdftosrc utility at http://www.circuitwizard.de/misc/pdftosrc.1.gz Please have a look whether one can live with it for now. Hope this helps to close the complaints from debian. Thanks a lot. Regards, Hartmut

1 0

[ pdftex-Bugs-444 ] buffer overflow with \pdfmatch
by noreply＠sarovar.org 29 Oct '05

29 Oct '05

Bugs item #444, was opened at 2005-10-29 19:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: buffer overflow with \pdfmatch Initial Comment: % The new \pdfmatch primitive will run into a buffer overflow with strings % longer than 1023 characters: % % (I am using 1.30.3 with Thanh's patches from pdftex.sarovar.org/src, % compiled under cygwin.) \def\x{1,2,3,4,5,6,7,8,9,0,} \def\testlist{% ,\x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x00,}% 1024 \ifcase\pdfmatch{,1,}{\testlist}\relax \fi % Also, if the pattern is too long: %\ifcase\pdfmatch{\testlist}{1}\relax \fi \bye, Robert. PS: Is there a simple way to escape all regex special characters in a string? ---------------------------------------------------------------------- >Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-29 21:08 Message: Logged In: YES user_id=929 see patch to utils.c. This makes makecstring() memory grow on demand. Also increase MAX_CSTRING_LEN in ptexmac.h to e. g. 10000000. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106

1 0

[ pdftex-Bugs-444 ] buffer overflow with \pdfmatch
by noreply＠sarovar.org 29 Oct '05

29 Oct '05

Bugs item #444, was opened at 2005-10-29 17:24 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) Assigned to: Nobody (None) Summary: buffer overflow with \pdfmatch Initial Comment: % The new \pdfmatch primitive will run into a buffer overflow with strings % longer than 1023 characters: % % (I am using 1.30.3 with Thanh's patches from pdftex.sarovar.org/src, % compiled under cygwin.) \def\x{1,2,3,4,5,6,7,8,9,0,} \def\testlist{% ,\x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x\x\x\x\x \x00,}% 1024 \ifcase\pdfmatch{,1,}{\testlist}\relax \fi % Also, if the pattern is too long: %\ifcase\pdfmatch{\testlist}{1}\relax \fi \bye, Robert. PS: Is there a simple way to escape all regex special characters in a string? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=444&group_id=106

1 0

documentation
by Reinhard Kotucha 28 Oct '05

28 Oct '05

Hi, is it possible to make documentation for pdftex and hyperref accessible to texdoc(1)? While the pdftex manual can be accessed if people know that it is called "pdftex-a" (it sounds like a joke if people say "Read the documentation" on a mailing list), the hyperref manual is inaccessible. On my system I get: $ locate manual.pdf | wc -l 164 Is it possible to solve it before TL is released? I would expect that "texdoc <packagename>" or "texdoc <progname>" provides something useful. Regards, Reinhard -- ---------------------------------------------------------------------------- Reinhard Kotucha Phone: +49-511-4592165 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotucha@web.de ---------------------------------------------------------------------------- Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ----------------------------------------------------------------------------

7 11

Re: [tex-live] documentation
by Heiko Oberdiek 28 Oct '05

28 Oct '05

On Thu, Oct 27, 2005 at 03:00:15PM -0300, George White wrote: > Quoting Heiko Oberdiek <oberdiek(a)uni-freiburg.de>: > > > On Thu, Oct 27, 2005 at 07:00:54AM -0300, George White wrote: > > > > > Quoting Reinhard Kotucha <reinhard.kotucha(a)web.de>: > > > > > > > >>>>> "Karl" == Karl Berry <karl(a)freefriends.org> writes: > > > > > > > > > Well, if you can make a patch for the texdoc .dat file, I can > > > > > install it :). > > > > > > > > I fear that, unlike texdoctk, texdoc simply uses ls-R as a database. > > > > > > > > Thomas recently mentioned that one can define aliases, but I think > > > > that it is best if the authors provide fixes. > > > > > > It may be best, but is it practical? Will aliases help when you have > > > dozens of manual.pdf files? > > > > > > I suspect it is much easier to make changes in texdoc to support > > > "package/manual". On systems that support symlinks one could process > > > the doc tree to make package/manual.pdf -> package/package.pdf. > > > > And how you want to solve the problem of several documentation > > files? One symlink can point to just *one* file. > > Hopefully the others will at least be be mentioned in manual.pdf, Perhaps somewhere, in many cases not: * Different language versions: manual-en.pdf, manual-de.pdf, ... The normal expectation is then, that the users that open manual-en.pdf see the English version, readers of manual-de.pdf the German version, ... It would be a surprise, if theses manual versions start with a list of links to the different language versions. And which language should be choosen for this part? * Separate source code documentation and user manual, articles, slides, ... > but > this emphasizes the point that, for many packages, the directory in the > doc tree is the real connection to the package and may contain multiple files > with generic names like manual.pdf that may indicated the type of content but > tell you nothing about the package. But you still have the directory! The current texdoc behaviour is not appropriate for documentation that consist of several files: TDS:doc/.../package/package.pdf % for manual TDS:doc/.../package/package.pdf % for source code doc -> you are running out of names -> it is not clear, what the type of content is -> redundant naming, you could strip the directory "package" level A more naturally naming convention is: TDS:doc/.../package/manual.pdf TDS:doc/.../package/source.pdf Possible ways to solve the texdoc problem: * The package author offers a document for texdoc with standardized name (e.g. texdoc-index.[pdf,html,...] that contains explanations and links to the package's documentation. TDS:doc/.../packageA/texdoc-index.pdf TDS:doc/.../packageA/manual.pdf TDS:doc/.../packageA/source.pdf TDS:doc/.../packageB/texdoc-index.html TDS:doc/.../packageB/manual.html TDS:doc/.../packageB/README Then texdoc also looks for this document (texdoc-index.*). * Or a separate data base is maintained with package overviews. (e.g. source in XML. PDF and HTML are automatically generated.) source/packageA.xml source/packageB.xml pdf/packageA.pdf pdf/pacakgeB.pdf html/packageA.html html/packageB.html Then texdoc also looks for this database. * Or texdoc shows the directory and let the user decide, which file\ he wants. * ... Yours sincerely Heiko <oberdiek(a)uni-freiburg.de>

1 0

[Fwd: Producing Tagged PDF or PDF/A from LaTeX (ISO 19005-1)]
by Rolf Niepraschk 25 Oct '05

25 Oct '05

-------- Original-Nachricht -------- Betreff: Producing Tagged PDF or PDF/A from LaTeX (ISO 19005-1) Datum: 25 Oct 2005 13:36:19 GMT Von: n05W43+mgk25(a)cl.cam.ac.uk (Markus Kuhn) Organisation: University of Cambridge, England Newsgruppen: comp.text.tex Is there any solution on the horizon for turning a LaTeX document into a "Tagged PDF" file, that is a PDF 1.4 file written in such a way that the underlying Unicode plaintext in it can be recovered smoothly (for easier searching, cut&paste, NLP parsing, Braille, speech synthesis, etc.). Background: The new international standard ISO 19005-1:2005 defines an "electronic document file format for long-term preservation" called PDF/A-1. This is basically a subset of PDF 1.4, with lots of nasty and dangerous stuff (JavaScript, external references, missing fonts, encryption, etc.) removed and various historic ambiguities in the PDF spec clarified. It was mainly developed to make PDF useful for legal-deposit purposes, All very good and commendable for anyone using PDF in electronic publishing and archival applications. However: Full compliance with the PDF/A-1 format requires that "Tagged PDF" is used, such that the underlying plaintext remains accessible for further processing. How could I do that from LaTeX? Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

1 0

[ pdftex-Patches-443 ] 512 zeros in Type1 fonts not copied anymore
by noreply＠sarovar.org 24 Oct '05

24 Oct '05

Patches item #443, was opened at 2005-10-24 22:41 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=443&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: 512 zeros in Type1 fonts not copied anymore Initial Comment: When embedding Type1 fonts in PDF files, it is not needed to copy the trailing 512 zeros; they are redundant. This has been suggested in the paper "Two Diet Plans for Fat PDF" by Thomas A. Phelps and Robert Wilensky. Reduces file size a little. Then /Length3 = 0, see Table 5.24 in the PDF Ref. v. 1.6. The tiny patch to writet1.c does this for pdfTeX. No change in the dvips portion. In the patch also the font matrix transform is streamlined by use of generic transform macros. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=443&group_id=106

1 0

[ pdftex-Bugs-441 ] Debug output of makecfilename
by noreply＠sarovar.org 22 Oct '05

22 Oct '05

Bugs item #441, was opened at 2005-10-22 09:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=441&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: Debug output of makecfilename Initial Comment: Hello, since pdfTeX 1.30.4, e.g. \pdfximage prints the file name twice, the first time stderr is used and messes up the output, e.g.: <screen_output lines="8"> This is pdfTeX, Version 3.141592-1.30.4 (Web2C 7.5.5) (./test.tex (./dir.tex antrschl.jpg [1 <./antrschl.jpg>] console.jpg [1 <./console.jpg>] img002.jpg [1 <./img002.jp g>]) ) Output written on test.pdf (3 pages, 451963 bytes). Transcript written on test.log. </screen_output> The line break in "<.\img002.jpg>" looks funny. The reason is some debug output in function makecfilename of utils.c: fprintf(stderr, " %s\n", name); Patch attached that removes that line. (With comment that at least marks the incompatibiliy introduced in 1.30.4 regarding file names, but that is another topic). Output after the patch is applied: <screen_output lines="5"> This is pdfTeX, Version 3.141592-1.30.4 (Web2C 7.5.5) (./test.tex (./dir.tex [1 <./antrschl.jpg>] [1 <./console.jpg>] [1 <./img002.jp g>]) ) Output written on test.pdf (3 pages, 451963 bytes). Transcript written on test.log. </screen_output> Perhaps the output is messed up by the web interface of the bug report system. There should be five lines. The funny line break in "<.img002.jpg>" is now the normal TeX line break because of screen line. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=441&group_id=106

1 0

Interesting Paper
by Hartmut Henkel 21 Oct '05

21 Oct '05

just found "Two Diet Plans for Fat PDF" by Thomas A. Phelps and Robert Wilensky, University of California, Berkeley. http://multivalent.sourceforge.net/Research/TwoDietPlans.pdf Regards, Hartmut

1 0