- ntg-pdftex - NTG Mailing Lists

Re: [pdftex] pdftex-0.12a
by Martin Schröder 25 Feb '04

25 Feb '04

On 2004-02-25 15:53:02 +0530, The Thanh Han wrote: > (changes have been also submitted to texlive sources) - the version is 1.12a-beta-20040225, not 0.12a - NEWS is not updated - hz.ch and misc.ch have no copyright header Regards Martin -- Martin Schröder, ms(a)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

2 1

Meeting in Darmstadt
by Martin Schröder 17 Feb '04

17 Feb '04

Hi, it seems that most of us will be in Darmstadt for the DANTE meeting. I suggest a meeting of pdfTeX developers. Wednesday? Best regards Martin -- Martin Schröder, ms(a)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

1 0

ptex entries
by Hans Hagen 16 Feb '04

16 Feb '04

Hi Martin, If we move the ptex entries to the info dict, they will be visible in the document properties (full acrobat) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE/POD/CTS Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

2 1

encoding vectors
by Hans Hagen 15 Feb '04

15 Feb '04

Hi, I occasionally run into (commercial) fonts that have gaps in their encoding vector. For instance, no 'sfthyphen', or no fi/fl/ffl/ffi ligatures. Of course one can handcraft a vector, but to keep thinsg simple I wonder how complicated it would be to have a fall back, say: - if no sfthyphen is present, then take the hyphen - if no fi ligature is present, output an f and i and cross your fingers for proper font based kerning If you look into the texnansi vector, yuo will notice that esp this sfthyphen has resulted in either taking or not taking a slot. Of course another option could be to patch afmtotfm to do a more rigourous check (remove ligs that are not in the font, remap sfthyphen). Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

3 7

bug in pdf inclusion / pdfetex
by Hans Hagen 11 Feb '04

11 Feb '04

Hi Fabrice, The latest binary you sent me fails on some pdf inclusion in a manual i'm currently upgrading. Is there a way to trap the bug trace in windows? I get this pop up screen which i cannot cut and paste. figures : dimensions of ./cols-002.pdf loaded from figurefile itself ./cols-002.pdf <./cols-002.pdf return code : 65280 run time : 5 seconds It's hard to create a test file because deleting a page changes the location of the error. BTW, the fact that the latest pdftex includes all file at the end Transcript written on error.log. ./cols-001.pdf ./cols-001.pdf ./cols-001.pdf ./cols-001.pdf ./cols-002.pdf ./cols-002.pdf ./cols-002.pdf ./cols-002.pdf ./cols-003.pdf ./cols-003.pdf ./cols-003.pdf ./cols-003.pdf ./cols-004.pdf ./cols-004.pdf ./cols-004.pdf ./cols-004.pdf ./cols-005.pdf etc is a drastic change and presumes that the files didn't change; i happen to have situations where the files are generated run time and therefore change -) not in this case but ... was something changed to the \immediate? Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

2 2

Re: [NTG-pdftex] pdftex-1.11b uniqueresname bug
by Hans Hagen 11 Feb '04

11 Feb '04

At 21:23 03/02/2004, Hartmut Henkel wrote: >Pdftex produces broken PDF when its HZ implementation is used with >\pdfuniqueresname = 1, like it is set in example.tex. Then xpdf issues >errors, e. g.: > >Error: Unknown font tag 'F54?:E3_+10' > >Reason is, that in the page contents stream there is e. g. some > >/F54?:E3_+10 > >but the page resources look like > >/Font << ... /F54+10?:E3_ ... > >The font_tag "+10" and resname_prefix "?:E3_" are swapped (and it's no >prefix anyway, more like an inbetweenfix). This can easily be cured by >just swapping two lines in pdftex.ch, then it's a postfix :-) > >--- pdftex.ch-orig Mon Oct 6 10:38:51 2003 >+++ pdftex.ch Tue Feb 3 20:47:41 2004 >@@ -1590,8 +1590,8 @@ > pdf_begin_text; > pdf_print("/F"); > pdf_print_int(k); >- pdf_print_resname_prefix; > pdf_print_font_tag(f); >+ pdf_print_resname_prefix; > pdf_out(" "); > pdf_print_bp(font_size[f]); > pdf_print(" Tf"); > >Seems to work then. Have fun! i wonder, doesn't it make sense to limit that /F^!*D^$@)!@($^ kind of names to /<characters and numbers> Hans

2 3

pdftex.cfg (was: pdf(e)tex status)
by Martin Schröder 03 Feb '04

03 Feb '04

On 2004-01-29 01:15:49 +0100, Staszek Wawrykiewicz wrote: > can you tell me about the status of expected changes to pdf(e)tex? Stasz, I want to fix the cfg problem in the next release (1.12a, planned for early February). > Just to recall, here is the current problem: > how to avoid reading pdftex.cfg while running pdf(e)tex --ini As I recall the main problem was not that a cfg was found and read but that it wasn't found and pdftex failed. I just want to make a missing cfg a non-fatal error. > I would vote for dumping the *default* output to the format, say > latex will use \pdfoutput=0, pdflatex will use \pdfoutput=1 Good idea. > So latex etc. could be linked just to pdfetex, without any other > command line switch (anyway not yet available). For such command&format > I'd suggest not reading pdftex.cfg at all (it sets things rather > concerned to pdf output). > > pdftex.cfg should be left as it is for commands&formats > which use pdf output by default. Just to avoid a mess with new > command line parameters for pdf(e)tex, more config files, > and... for transparent use as (e)tex replacement as the main > engine (actually not true). True. > Ps. I'm overflooded by spam mails, often sent from your, Sebastian > and other people addresses... Yes. Spammers like to fake their addresses and use publically known addresses. Unfortunately ours are all over the web. :-( Use SpamAssassin with procmail. :-( Best regards Martin -- Martin Schröder, ms(a)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

2 3

Fwd: feature request llx etc
by Hans Hagen 23 Jan '04

23 Jan '04

>Hi Martin, > >Occasionally we need to have access to the llx/lly coordinates of a >graphic; in EPS this is no problem, but ... > >how about providing \pdfxformllx\xformid (etc: llx, lly, ulx, uly) > >(background: Ross/Wendy/Me are working on label overlay features [there >is/will be a plug in for AI to provide some of the info needed] and fro >that we need to have access to the "origin" > >Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

2 2

Xpdf 3.00 - a PDF viewer for X
by Martin Schröder 23 Jan '04

23 Jan '04

This means pdf1.5 is on the horizon and will be in 1.2 (which should be there before BachoTeX). Best regards Martin -- Martin Schröder, ms(a)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

1 0

pdftex.cfg (was: Latest pdftex binaries)
by Martin Schröder 19 Jan '04

19 Jan '04

On 2004-01-18 18:25:48 +0100, Hans Hagen wrote: > So, martin: is there any reason for an abort when no config is found? > Defaulting to outut_format 0 also honors Staszeks wish to default to dvi I don't see any; in fact I think it's a bug to abort when no config can be found. I'll fix it. Best regards Martin -- Martin Schröder, ms(a)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

3 2

Missing encodings, missing fonts
by Martin Schröder 14 Jan '04

14 Jan '04

Hi, currently missing encoding files and missing pfbs only generate warnings and lead to incorrect pdfs. Any objections against turning these warnings into errors? The same probably applies to mapfiles. Best regards Martin -- Martin Schröder, ms(a)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

3 4

RE: [pdftex] current filename and current filedate ?
by Hans Hagen 05 Jan '04

05 Jan '04

At 23:00 04/01/2004, you wrote: >hi hans: this would be great news, indeed. (I liked \include{} because >it requires an operating system file system operation, just like current >file name/date). if you are addings this, please add individual filename >date/time, too, not just jobdate. I would also add a "\system{}" macro, >instead of a write18 macro, where the output is directly inserted as text >into the output stream; it would be mildly safer than write18, and more >functional in most situations. an option for that could be something: \openin\tempread=somename.suffix \pdffiledate\tempread \pdffilesize\tempread etc. This has several advantages: (1) it runs on top of the current file mechanism, (2) is can work with the kpse file search library (handy when the path is not known) and (3) implementing anything too far from tex's internals can be tricky with regards to how it end up in the string pool etc. With regards to \system{...}, maybe some pipe could be implemented, \immediate\openin\read18{whatever} or so ... >I actually am surprised that this feature still needs a lot of work to >work on many different systems. I would guess Unix systems (including >Mac) and Windows machines these days all work pretty much the same way to >get datefile /time via a stat() call. Compilers with Unix+Win >compatibility just have to cover 99% of all TeX installation these >days. And, if this feature does not work on a particular system, it won't >break the world---just the same as when write18 does not work or when >\today outputs the wrong date or no date on a system that does not keep >time. (ok, so they no longer exist.) it has to with the fact that extension are implemented on top of 25 years of accumulated tex code (a mix of pascal and c and libraries); also, tex is (and has to be) extremely reliable since it's used all over the world, also by non system experts and hackers, so every extension should *work*, i.e. in this respect tex is not like the average open source thing, there is so much related and derived stuff around, and compatibility is not only a big issue here, but also the reason that tex is still around; on the other hand, extension are possible and part of the game, so in the end ... > -----Original Message----- > From: Hans Hagen [mailto:pragma@wxs.nl] > Sent: Sun 1/4/2004 1:42 PM > To: Welch, Ivo > Cc: > Subject: Re: [pdftex] current filename and current filedate ? > > > > At 02:46 20/12/2003, you wrote: > > >* Programming-wise, it would not be a big step to add two macros for > >\currentfile and \currentfiledate. There is no operating system > on which > >this would likely be difficult. Are there any modern C > implementations > >without a basic Unix-like stat() call? > > Already on the pdftex 'to be implemented in a next release list are' > > \pdfhours > \pdfminutes > \pdfseconds > \pdfmilliseconds > > (needed since \time is too unprecise, which renders it useless > for for > instance random number generation); so there is no problem for adding > > \pdfjobnamedate > \pdfjobnamesize > \pdfjobfullpath > > Such extensions may sound trivial but since their implementation is > platform independent [which has consequences in many small areas > of the > source code tree] they end up on to do lists (next major release); > > >* We already have facilities inside latex to get the overall > \jobname > >(really a filename). We also already have facilities for the > current > >date/time. > > hm, \jobname is special in itself, it's also an example of the > mess you may > end up in: catcodes of tokens in reported filename in this case > > >So, if we can have \write18, \include, and \jobname, > \currentfile and > >\currentfiledate is not very different. > > what's \include suppose to do? > > Hans > > ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

2 2

pdftex-1.11b fontmap patches
by Hartmut Henkel 31 Dec '03

31 Dec '03

Hi pdftex fans, there is a new experimental patch for pdftex-1.11b at: http://www.circuitwizard.de/pdftex/patch2/pdftex-avlpatch2-newest.tgz which is now http://www.circuitwizard.de/pdftex/patch2/pdftex-avlpatch2-20031231-0019.tgz News are: 1. New primitive \pdfmapline{...}, \pdfmapline{+...}, \pdfmapline{=...}, \pdfmapline{-...} allows to enter or delete single map lines. Similar modes as with the \pdfmapfile{} command. 2. If a PDF file is to be embedded, it is now early checked, whether the corresponding font files are available. If a font file from the map listing is not existing, the font coming with the embedded PDF file is used instead, without warning. The case, that a PDF file is embedded, and then the font is missing in the final PDF file e. g. due to a typo in the fontfile name, should not happen any more. To do this, I have added another search tree, which contains only the names of the font files actually requested, with path and availability info. Once a file name with full path is in this tree, looking the full path up there should be faster than asking the kpse_find_file() function. 3. Repaired empty \pdfmapfile{} case (which was wrong in my former patch), and now also an empty \pdfmapline{} clears the map item list. The mapfile warning has also gone. 4. Tidied up fm_scan_line(). Now the map line handling is clearly separated from the map file handling. It seems to run basically with all test files here, but the really hard testing part, especially against all these nifty MM instance cases is to be done. There are sooo many odd cases... That's the "end-of-2003-patch" status from here. I would be glad, if you find time to try it out. Regards, Hartmut ------------------------------------------------------------------------ Dr.-Ing. Hartmut Henkel In den Auwiesen 6, D-68723 Oftersheim, Germany E-Mail: hartmut_henkel(a)gmx.de http://www.circuitwizard.de ------------------------------------------------------------------------

1 0

Re: Questions about mapfile handling
by Hans Hagen 11 Dec '03

11 Dec '03

At 00:12 16/11/2003, Hartmut Henkel wrote: >Disabling this mechanism seems to be rather easy, as it is triggered >only from one place. Would a global \pdfxobjkeepfonts (default 0) have >the right name? sounds ok to me > > indeed, esp the slant is a problem (but maybe even pseudo small cap > > files): > >SlantFont and ExtendFont we have. But how can one currently see from an >entry in the map file (like " SCFont "), that it's a pseudo small-cap >file? this is indeed a problem, (and one reason more for me to use a different naming scheme than kb) fortunately those pseudo caps are seldom used Hans

3 4

Re: [pdftex] \pdfmapfile-Patch
by Hans Hagen 16 Nov '03

16 Nov '03

Hi, great, those extensions! fabrice will generate me binaries one of these days ... so then i can test them! > The font map entry management is now taken over by --- AVL-trees :-) so this brings us to: \pdfnewtree \nameoftree \pdfaddtotree \nameoftree {string} {tokens} \pdfgetfromtree \nameoftree \pdfresettree \nameoftree {string} which will give us a huge amount of hash space >Actually the whole former fm_tab list is replaced by a tree, which were >lots of "trivial" mini changes (that's where the bugs are :-), but >scattered over many files, therefore the many diffs. But this should now >allow with high speed to register map entries, find existing ones, and >replace/overload them by newer ones, if needed. There is also a new flag >in the fm_entry structure, which tells, whether a font is already in use >(the info might also be elsewhere but this flag came in handy). good, let's get rid of the old mess >Another change is, that now \pdfmapfile{} primitives are also active >after the first page, as many as you need, wherever. As long as a font >is not in use, its entry is overloaded when \pdfmapfile{++mapfile.map} >is given on any page. A font is actually used, when the first letter of >the font is given. Then also a fresh mapfile scan is done (before this >font is used), if new mapfiles are available. good thinking! >I have further re-organized the function fm_read_info() in mapfile.c, >and separated it into file and line scanning functions, for hopefully >better legibility. (I had to remove Heiko's fine hashing patch, as it >conflicted with the AVL stuff; the hashing is taken over by the tree >with similar speed). > >In principle, it should also be possible with a little work (but not >implemented yet) to say \pdfmapfile{-mapfile.map}, which would _remove_ >all entries matching those in this file, if not already in use. Any >application for this? Also possible (but not yet implemented) should be >something like: > >\pdfmapfile{*++phvr8r Helvetica-Down "TeXBase1Encoding ReEncodeFont"...} > >Any need for such a direct map-line registering? hm, one never knows ... i found out that sometimes when including files, pdftex makes invalid files due to the fact that it tries to load fonts (when it finds a tfm file, it also assumes that there is a map file, but when the map is not loaded, it results in errors (non resolved names). So, i wonder if it's possible to add a test in the pdf inclusion partwhere each tfm file to be used is checked against the loaded map entries and when not found there, no clever things are done: currently: - pdf to be included uses font ABC - pdftex locates whatever.tfm that seems to match ABC - pdftex produced invalid pdf if map file has no entry for whatever.tfm replacement: - pdf to be included uses font ABC - pdftex locates whatever.tfm that seems to match ABC - pdftex checks map files for entry for whatever.tfm - pdftex ignores tfm file for inclusion when no entry is found maybe we also need: \pdfignorefontname=1 which let map file loading skip the "Full Name" entry (another source of problems) Hans

3 5

[pdftex] \pdfmapfile-Patch
by Hartmut Henkel 10 Nov '03

10 Nov '03

Hi pdftex fans, there is another experimental patch for pdtex-1.11b: This tackles with two problems (see Hans' E-Mail below): 1. Mapfiles could not be read in after the first page. 2. There is an annoying warning "duplicates ignored" if the same mapfile line appears twice; overloading was not possible. With the patch, there are now the following options: * \pdfmapfile(mapfile.map) starts fresh map set (only at start). * \pdfmapfile(+mapfile.map) appends map, warns about duplicate entries and then ignores them. New: * \pdfmapfile(++mapfile.map) replaces former map line entries for all matching fonts, which are not yet in use. The font map entry management is now taken over by --- AVL-trees :-) Actually the whole former fm_tab list is replaced by a tree, which were lots of "trivial" mini changes (that's where the bugs are :-), but scattered over many files, therefore the many diffs. But this should now allow with high speed to register map entries, find existing ones, and replace/overload them by newer ones, if needed. There is also a new flag in the fm_entry structure, which tells, whether a font is already in use (the info might also be elsewhere but this flag came in handy). Another change is, that now \pdfmapfile{} primitives are also active after the first page, as many as you need, wherever. As long as a font is not in use, its entry is overloaded when \pdfmapfile{++mapfile.map} is given on any page. A font is actually used, when the first letter of the font is given. Then also a fresh mapfile scan is done (before this font is used), if new mapfiles are available. I have further re-organized the function fm_read_info() in mapfile.c, and separated it into file and line scanning functions, for hopefully better legibility. (I had to remove Heiko's fine hashing patch, as it conflicted with the AVL stuff; the hashing is taken over by the tree with similar speed). In principle, it should also be possible with a little work (but not implemented yet) to say \pdfmapfile{-mapfile.map}, which would _remove_ all entries matching those in this file, if not already in use. Any application for this? Also possible (but not yet implemented) should be something like: \pdfmapfile{*++phvr8r Helvetica-Down "TeXBase1Encoding ReEncodeFont"...} Any need for such a direct map-line registering? You find a .tgz-file with the experimental patch (mostly diffs) at: http://www.circuitwizard.de/pdftex/patch2/pdftex-avlpatch2-20031109.tgz Small print: This is an experimental patch, in a rather early phase, and buggy. No warranty whatsoever! It just happens to run over the few test files I have here :-) Much more testing is needed. Particularily dark corners are extended fonts... Anyway, my current feeling is, that these AVL-trees would really help in quite a few corners of pdftex, to improve organization, versatility, and speed. Is there anybody out there who would like to help with debugging? Comments, bug reports welcome! Best Regards Hartmut On Thu, 6 Nov 2003, Hans Hagen wrote: > At 00:59 05/11/2003, Hartmut Henkel wrote: > >On Tue, 4 Nov 2003, Hans Hagen wrote: > > > > > ...(actually dups should overload previous ones) > > > >Currently one adds a mapfile by "map myfonts.map" for fresh create, > >or "map +myfonts.map" for append. It seems that a change in config.c > >should be possible to allow also "map -myfonts.map", in which case > >myfonts.map would be read in _before_ other map files, so in effect > >it would overload them. Would this help? > > sounds ok to me although we can run into ptoblems when map files can > be read after the first page (currently pdftex does not permit that > which is painful because it complicates mid document font changes) > > so, next to -name we also need =name meaning 'load now and overload > previous entries unless the font is already used' ------------------------------------------------------------------------ Hartmut Henkel, Oftersheim, Germany http://www.circuitwizard.de ------------------------------------------------------------------------

3 2

Re: [pdftex] Building pdfTeX 1.11b fails
by Martin Schroeder 16 Oct '03

16 Oct '03

On 2003-10-14 10:47:40 +0200, Martin Schröder wrote: > On 2003-10-14 08:32:38 +0200, Felix Neubauer wrote: > > ! Sections do not match (file ./tex.ch, l.1280). > > (file ./pdftexdir/tex.pch, l.55). > > tex.pch is screwed. Will fix it. web2c/pdftexdir/tex.pch and web2c/tex.ch in source are out of sync (and in sync in source.development). :-( Best regards Martin -- Martin Schröder, ms(a)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

1 3

[Bugfix] /Rotate
by Martin Schroeder 06 Oct '03

06 Oct '03

Hi, we have the first bug(fix) for 1.11a: When included pdfs have the /Rotate key set to 90 or 270, they become displaced. Attached are two files: - rotate.tex Generates a 4 page document where each page is rotated differently, has a cropbox set and marks to measure the displacement. - test.tex Includes all pages of rotated and shows displacement. I've just submitted a bug fix (#4094); please test it. Thanks to Dr. Thomas Risse for submitting the bug. Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

1 1

Speeding up PdfTeX
by Hartmut Henkel 04 Oct '03

04 Oct '03

Hi pdfTeX fans, this is just to announce, that there is another spare time patch for pdfTeX on my home page, which copes with the slow-down of the program, if files with a lot of links are to be processed. I have built in AVL trees for quicker finding of items in the linked object list. Yes, this is the 3rd patch of the AVL-Trilogy :-) It's actually a minor issue, very low amount of changes in the web code. To give you an impression about the speed gain, here are some test run results: with Patch Original -------------------------------------------- 1000 links 44 pages 2.14s 2.61s 2000 links 87 pages 3.42s 4.72s 5000 links 218 pages 7.3s 18s 10000 links 435 pages 14s 63s 20000 links 870 pages 30s 208s 50000 links 2174 pages 80s 1590s You see that the patch is only perceptible/interesting, if .tex files are heavily linked. But this can quite easily happen, if the document is automatically produced, e. g. from some database, and if it contains lots of commodity links. Anyway... The patch (AVL-Patch 3) is on my homepage. I would be glad to know, if anybody has thought about something similar or has tried out the patch. Have fun! Greetings Hartmut ------------------------------------------------------------------------ Hartmut Henkel, Oftersheim, Germany http://www.circuitwizard.de ------------------------------------------------------------------------

1 0

MacKichan Software
by Martin Schroeder 29 Sep '03

29 Sep '03

Hi, I recently learned that MacKichan Software is shipping pdfTeX (and a bunch of other web2c software, e.g. Omega) with their products Scientific Word and Scientific Workplace. Is there any contact between them and the pdfTex or web2c developers? It was new to me (and Hans). Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

4 13

Re: xcolor1.tex
by Staszek Wawrykiewicz 12 Sep '03

12 Sep '03

On Thu, 11 Sep 2003, Uwe Kern wrote: > Staszek Wawrykiewicz <staw(a)gust.org.pl> schrieb am 10.09.03 20:40:48: > > > > I've failed to run pdflatex xcolor1.tex > > > > Illegal unit of mesure (pt inserted). > > l. 207 {\DisplayColor{\nR}{\nG}{\nB}}}} > > Since `pdflatex xcolor1.tex' runs well on my system, > I assume that your problem could be a version or configuration issue. > Therefore, I need some more information to track the > possible source of the misbehaviour. >.... > pdftex.def 2002/06/19 v0.03k graphics/color for pdftex I found it! We are using now for TeXLive pdftex.def 2003/06/20 v0.10a-BETA graphics/color for pdftex When renaming pdftex003.def to pdftex.def compilation goes well. pdftex.def has so many authors so I Cc to the pdftex list. ;-) -- Staszek Wawrykiewicz StaW(a)gust.org.pl

3 3

Re: Problem with latest pdfTeX 1.11a release?
by Martin Schroeder 11 Aug '03

11 Aug '03

On 2003-08-05 09:35:43 +0200, Gerben Wierda wrote: > Problem > > >running `pdfetex -ini -jobname=pdfxmltex -progname=pdfxmltex > >&pdflatex pdfxmltex.ini' ... > >This is pdfeTeX, Version 3.141592-1.11a-2.1 (Web2C 7.5.2) (INITEX) > >entering extended mode > >(/usr/local/teTeX/share/texmf.local/tex/xmltex/config/pdfxmltex.ini > >Error: pdfetex (file pdftex.cfg): cannot open config file > > ==> Fatal error occurred, the output PDF file is not finished! > > Compare with a recent source.development binaries (everything else is > the same) > > >running `pdfetex -ini -jobname=pdfxmltex -progname=pdfxmltex > >&pdflatex pdfxmltex.ini' ... > >This is pdfeTeX, Version 3.141592-1.11a-beta-20030718-2.1 (Web2C > >7.5.2) (INITEX) > >entering extended mode > >(/usr/local/teTeX/share/texmf.local/tex/xmltex/config/pdfxmltex.ini > >LaTeX2e <2001/06/01> > >Babel <v3.7h> and hyphenation patterns for american, british, french, > >german, n > >german, dutch, nohyphenation, loaded. > >(/usr/local/teTeX/share/texmf.local/tex/xmltex/base/xmltex.tex > >xmltex version: 2002/06/25 v1.9 (Exp) > > Looks like a possible problem in pdftex to me. Ordinary TeX ini works > well in both cases. Looks like a case of http://tug.org/pipermail/tex-live/2003-August/003974.html Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

7 10

Re: [NTG-pdftex] Re: Problem with latest pdfTeX 1.11a release?
by Hans Hagen 11 Aug '03

11 Aug '03

At 08:26 08/08/2003 +0200, Staszek Wawrykiewicz wrote: >On Thu, 7 Aug 2003, Thomas Esser wrote: > > > I'd prefer a solution wich is better than n*m entries in texmf.cnf (n = > > number of formats, m = number of tex engines). > > > > Solution a) > > > > (does not really solve the n*m problem, but provides a good > > default-TEXINPUTS and has other advantages): > > > > ENGINE variable, set by each engine, but with different values (not > > depending on progname, but on the real engine). It could have the > > following values (examples): > > > > engine $ENGINE > > ============================== > > pdfetex {pdftex,etex,tex} > > etex {etex,tex} > > eomega {omega,etex,tex} > > > > If every engine defines that $ENGINE, than we could have e.g. > > TEXINPUTS = .;$TEXMF/$ENGINE/{generic,}// > > TEXINPUTS.latex = .;$TEXMF/$ENGINE/{latex,generic,}// > > > > This solution also takes care of "behind the scene" changes, e.g. > > if latex switches from tex to etex as engine. > > > > Solution b) > > Drop all texmf/pdftex, texmf/pdfetex, texmf/omega, ... things in > > favor of texmf/tex. History has shown that most macro packages > > which are not written for "tex", but for some other engine > > already detect the engine. There are only very few conflicts > > between these trees, one is e.g. webmac.tex, but that can easily > > be fixed by replacing tex/plain/base/webmac.tex with a wrapper > > which first detects the engine and then ready either the "real" > > webmac.tex or pdfwebmac.tex. > > > > b) should be discussed on the TDS list if other people share my opinion. > > BTW: my favorite solution is b). > > > > Thomas > >Great idea! I'd vote for b) and suggest it for TL 2003 sounds ok to me, but why not also implement $ENGINE as variable to be set by the engine (one never knows when this will come in handy) another related problem: - pdftex differs from dvips which is why the texmf/pdftex path cannot go - pdftex.cfg is now common for all macropackages, while i would like a package dependent one with regards to the cfg file: context has one format that deals with dvi and pdf output; therefore i don't like the idea that pdf output is hardcoded in the cfg file; (ok, i can handle it at the macro level) since pdftex is 100% dvi compatible, why is there still latex/pdflatex, tex/pdftex, etc ; we could have much less formats (and generation) when the relevant macro packages should simply set \pdfoutput=1 which they have to do anyway; users have to load pdf specific functionality and that is the moment the macro package can set the flag; removing the dupplication would also make it more easy to explain to users what is going on. currently there is no control from within the macro package where files are looked for, apart from hard coded paths . .. and combinations; maybe the core file handler can be extended so that we can say things like \input {$texmf-local,$texmf}/somefile or \input [::texmf-local,::texmf]/somefile if we want to get rid of potential clashes with catcodes Hans Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- information: http://www.pragma-ade.com/roadmap.pdf documentation: http://www.pragma-ade.com/showcase.pdf -------------------------------------------------------------------------

2 5

Patch CreationDate
by Heiko Oberdiek 11 Aug '03

11 Aug '03

Hello, Patch CreationDate If /CreationDate is not given by \pdfinfo, then a default is used by computing the string by the current setting of \year, \month, and \time. Problem A: The time zone is not set. See the discussion in de.comp.text.tex, "[pdftex] Zeitzone von CreationDate" Valentin Schwamberger observed that his AR/Windows shows then the time as GMT. Problem B: It is easy to fool pdfTeX: * Setting \year to a number less or greater than 4 digits. * Setting \year, \month, \date, \time to invalid numbers, eg.: \month=13 The result are invalid dates. The following patch tries to solve these problems: * Time zone detection by glibc's strftime("%z"). * The current time is used, not \year, \month, ... Patch files based on 2003/07/30 v1.11a: utils.c.diff for TeX/texk/web2c/pdftexdir/utils.c pdftex.ch.diff for TeX/texk/web2c/pdftexdir/pdftex.ch pdftex.defines.diff for TeX/texk/web2c/pdftexdir/pdftex.defines Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> --

3 19

freshmeat
by Martin Schroeder 06 Aug '03

06 Aug '03

Hi, I've submitted a project description of pdfTeX to freshmeat (http://freshmeat.net/) as http://freshmeat.net/projects/pdftex/ Will keep you informed. Best regards Martin -- Martin Schröder, MS(a)ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

1 1