- ntg-pdftex - NTG Mailing Lists

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