forget about dvips, as far as i know, pdftex things made it back into dvips, so that can happen again this time; let's not carry the burden from the past

I am not aware of many things that dvips has taken over from pdftex. The only thing I know is the font subsetting module which origins from dvips. It was improved for pdftex and put back into dvips. Clearly, this was painless for dvips. As for other new stuff, I suggest that you don't just assume that dvips will follow everything. Better get in touch with Tomas Rokicki before doing that. Thomas

i'm not that familiar with dvips; how different are the map files?

pdftex has a numeric "bit" field that is rarely used (dvips does not have it) pdftex can omit the ps-fontname (for dvips, you can't) That's it (at least afaik). So, most files are well perfectly sharable. Users of teTeX can just drop dvips-style map files into updmap and it generates a fine map for pdftex out of it (updmap automatically omits the ps-fontname if Slant/Extend is used; pdftex should be fixed to make this unnesessary). Thomas

Let us not forget "/PaintType 2 def" in a dvips fontmap, which places that entry in the Type 1 dictionary and Type 1 rasterizers understand. Not so with PDF files. The outline paint type has to be set with a text state operator in a PDF file -- the Type 1 dictionary value is ignored. Tom On 2003/02/18 at 08:55, Hans Hagen wrote:

At 11:03 PM 2/17/2003 +0100, Thomas Esser wrote:

...

...

i'm not that familiar with dvips; how different are the map files?

pdftex has a numeric "bit" field that is rarely used (dvips does not have it) pdftex can omit the ps-fontname (for dvips, you can't)

That's it (at least afaik).

So, most files are well perfectly sharable. Users of teTeX can just drop dvips-style map files into updmap and it generates a fine map for pdftex out of it (updmap automatically omits the ps-fontname if Slant/Extend is used; pdftex should be fixed to make this unnesessary).

so, how about something -"fontname" which tells pdftex to ignore the fontname (which sometimes is handy) andis ignores by dvips?

also, dvips can ignore the numeric bit, which brings them close together

On 2003-02-17 14:47:23 +0100, Martin Schröder wrote:

It's in (#2878). Porting this to hash.h is left as an exercise

Any open bugs left? Major changes since 1.10a ------------------------- - Bugfix: When setting the /Producer, /Creator or /CreationDate keys with /pdfinfo pdfTeX would also insert default values which caused duplicate keys in the info dict (see http://tug.org/pipermail/pdftex/2003-February/003524.html). - The reading of mapfiles is much faster (see http://tug.org/pipermail/pdftex/2002-July/002843.html). - Bugfix: AR5 had problems with the CTM when displaying in "fit visible" mode (see http://tug.org/pipermail/pdftex/2002-May/002688.html). - Bugfix: str_in_str had wrong indices (see http://tug.org/pipermail/pdftex/2002-March/002367.html). - Bugfix: decimal_digits defaulted to 0, which caused problems with included images when including pdfs (see http://tug.org/pipermail/pdftex/2003-February/003518.html). It now defaults to 4. - Bugfix: the type of included images was decided based only on the extensions; now pdfTeX looks for magic bytes at the start of files (see http://tug.org/pipermail/pdftex/2003-February/003519.html) -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2003-02-17 15:45:51 +0100, Heiko Oberdiek wrote:

On Mon, Feb 17, 2003 at 03:26:04PM +0100, Martin Schroeder wrote:

...

Any open bugs left?

Yes, "Bug LiteralSpaceFirstSpace", see my posting in the pdfTeX mailing list of 2002/02/16. But I do not have a good fix (only a wild and quite untested guess).

I'd like to release 1.10b tomorrow. Anything that must be fixed till then? For LiteralSpaceFirstSpace I'd like to have Thanh's blessing for a fix. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2003-02-25 06:58:18 +0700, The Thanh Han wrote:

this fix must be tested very well -- otherwise it can break everything.

Which is why I haven't included any patch yet. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2003-02-26 13:09:06 +0100, Martin Schröder wrote:

I've moved the version to 1.10b (#2932). Sebastian, would you please integrate it and update source.tar.bz2?

Not yet -- Hartmut just found a potential overflow in the non-pdf-inclusion. Stay tuned. :-( Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

Hi Martin, Can you also add a primitive \pdftrailer which acts like the catalog but adds content to the trailer object? We may need this for reaching pdf/x compatibility. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@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 -------------------------------------------------------------------------

On 2003-02-26 20:34:46 +0100, Martin Schröder wrote:

On 2003-02-26 19:01:18 +0100, Hans Hagen wrote:

...

Can you also add a primitive \pdftrailer which acts like the catalog but adds content to the trailer object? We may need this for reaching pdf/x compatibility.

Will do in 1.11a

#3321: - New command \pdftrailer analogue to \pdfcatalog whose argument end up in the trailer dictionary. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10

Hi pdftex fans, function convertNumToPDF() has the feature, that if it gets numbers with 6 nonzero digits after the decimal point, it will not append a '\0' to the number string in the buffer. Then you get more than 6 digits after the point: whatever is left in the buffer until the next '\0'. And the rounding isn't clear. In the patched version below the rounding is at +/- 1/2 eps; the check for small numbers can be omitted by the way. Here is the output from the test program below for some numbers: input <orig> <patched> 10.00005000 <10.000049> <10.00005> 2.12345600 <2.1234569> <2.123456> 0.00000040 <0> <0> 0.00000050 <0> <0.000001> 0.00000100 <0.0000019> <0.000001> 9.00000000 <9> <9> 9.99999940 <9.9999999> <9.999999> 9.99999950 <9.9999999> <10> 9.99999990 <9.9999999> <10> 10.00000040 <10> <10> 10.00000050 <10> <10.000001> 10.00000100 <10> <10.000001> 10.00000200 <10.000002> <10.000002> 9.99999990 <9.9999992> <10> 9.49999949 <9.4999992> <9.499999> 9.49999950 <9.4999992> <9.5> 9.49999951 <9.4999992> <9.5> Below is the program for producing this list with the patch. Have fun. Greetings Hartmut #include #include #include static char *convertNumToPDF_orig(double n) { /* converts double to string; very small and very large numbers are NOT * converted to scientific notation. * n must be a number or real confirming to the implementation limits of * PDF as specified in appendix C.1 of the pdf ref. * These are: * maximum value of ints is +2^32 * maximum value of reals is +2^15 * smalles values of reals is 1/(2^16) */ static int precision = 6; static int fact = (int) 1E6; /* must be 10^precision */ static double epsilon = 1E-6; /* must be 10^-precision */ static char buf[64]; // handle very small values: return 0 if (fabs(n) < epsilon) { buf[0] = '0'; buf[1] = '\0'; } else { char ints[64]; int bindex = 0, sindex = 0; int ival, fval, i; // handle the sign part if n is negative if (n < 0) { buf[bindex++] = '-'; n = -n; } // handle the integer part, simply with sprintf ival = (int) floor(n); n -= ival; sprintf(ints, "%d", ival); while (ints[sindex] != 0) buf[bindex++] = ints[sindex++]; // handle the fractional part up to 'precision' digits fval = (int) floor(n * fact); if (fval) { // set a dot buf[bindex++] = '.'; sindex = bindex + precision - 1; // fill up trailing zeros with the string terminator NULL while (((fval % 10) == 0) && (sindex >= bindex)) { buf[sindex--] = '\0'; fval /= 10; } // fill up the fractional part back to front while (sindex >= bindex) { buf[sindex--] = (fval % 10) + '0'; fval /= 10; } } else buf[bindex++] = 0; } return (char *) buf; } static char *convertNumToPDF(double n) { /* converts double to string; very small and very large numbers are NOT * converted to scientific notation. * n must be a number or real confirming to the implementation limits of * PDF as specified in appendix C.1 of the pdf ref. * These are: * maximum value of ints is +2^32 * maximum value of reals is +2^15 * smalles values of reals is 1/(2^16) */ static int precision = 6; static int fact = (int) 1E6; /* must be 10^precision */ static double epsilon = 1E-6; /* must be 10^-precision */ static char buf[64]; char ints[64]; int bindex = 0, sindex = 0; int ival, fval, i; // handle the sign part if n is negative if (n < 0) { buf[bindex++] = '-'; n = -n; } // handle the integer part, simply with sprintf n += 0.5 * epsilon; ival = (int) floor(n); n -= ival; sprintf(ints, "%d", ival); while (ints[sindex] != 0) buf[bindex++] = ints[sindex++]; // handle the fractional part up to 'precision' digits fval = (int) floor(n * fact); if (fval) { // set a dot buf[bindex++] = '.'; sindex = bindex + precision; buf[sindex--] = '\0'; // fill up trailing zeros with the string terminator NULL while (((fval % 10) == 0) && (sindex >= bindex)) { buf[sindex--] = '\0'; fval /= 10; } // fill up the fractional part back to front while (sindex >= bindex) { buf[sindex--] = (fval % 10) + '0'; fval /= 10; } } else buf[bindex++] = 0; return (char *) buf; } int main() { double z[] = { 10.00005, 2.123456, 0.0000004, 0.0000005, 0.000001, 9, 9.9999994, 9.9999995, 9.9999999, 10.0000004, 10.0000005, 10.000001, 10.000002, 9.9999999, 9.49999949, 9.4999995, 9.49999951 }; char *buf_orig, *buf; int i; printf("input <orig> <patched>\n"); for (i = 0; i < 17; i++) { buf_orig = convertNumToPDF_orig(z[i]); buf = convertNumToPDF(z[i]); printf("%11.8f <%s> <%s>\n", z[i], buf_orig, buf); } return 0; }

Hi pdfTeX fans, in the last few days I have fiddled around with application of AVL trees, and as an experiment replaced the linked list PdfDocuments in file pdftoepdf.cc by an AVL search tree. It was quite straight-forward. Once the coredumps go away, it works :-) The patch you find on my homepage: w w w . c i r c u i t w i z a r d . d e I use the nice AVL implementation GNU libavl by Ben Pfaff, it is compact, looks very mature/stable, extremely well documented, and it's unter the GNU Public License, Good. These AVL trees give a pretty high lookup speed, so one probably might give them a try for other dictionary lookup tasks within pdfTeX. (However I already failed miserably before, when trying to replace the fm_tab list for mapfile entries by such an AVL tree. The fm_tab list stuff is so widely scattered over many places within the pdftex sources, that a replacement by a search tree would be a major overhaul; but it seems to be possible. Anyway we have the nice hashing by Heiko.) The patch is still rather raw, but as it basically does the wanted, I thought I should push it out for discussion. Greetings Hartmut

Hi, there's another _experimental_ patch: I have replaced the fm_tab array for fontmaps in pdftex by two AVL trees, and modified the fmlookup(), tfmoffm() etc. functions accordingly. Now the pdffontmap list in pdftex.ch contains pointers (instead of indices) to the fm_entry entries. The mapfile reading speed then is great: 100000 lines of mapfile need a fraction of a second on my 400 MHz PC. AVL in principle allows to replace fm_entry entries while filling the tree. Beware: The patch is buggy, most likely around reading TT fontmaps, as I need to understand things around the mk_ext_fm() function; never came along TTFs. For the curious, the patch is at w w w . c i r c u i t w i z a r d . d e Greetings Hartmut On Thu, 20 Feb 2003, The Thanh Han wrote:

Hi,

I would prefer using consistent structure. Thus if we consider using libavl reasonable, we should use it everywhere when possible.

It seems that currently pdftex deletes/re-reads documents when they are to be multiply included, see the log for a 4-page pdf file, its page 1 included by: \pdfximage width \hsize page 1 {prod_brochure.pdf} \hbox{\pdfrefximage\pdflastximage} \vfill\eject \pdfximage width \hsize page 1 {prod_brochure.pdf} \hbox{\pdfrefximage\pdflastximage} \vfill\eject \end See the log below. Shouldn't such a request include the file only once, and later only make a reference to the first page object? When I uncomment the (pdf_doc->occurence)--; line, I get much smaller file size, 120278 bytes in this case. Is the occurence stuff broken, or do I do something wrong? Greetings Hartmut Log (with #define DEBUG): This is pdfTeX, Version 3.14159-1.10a (Web2C 7.4.5) (./y.tex{/usr/local/teTeX/share/texmf/pdftex/config/pdftex.cfg} Creating ./prod_brochure.pdf (0) Reading information on ./prod_brochure.pdf [1{/usr/local/t eTeX/share/texmf/dvips/config/pdftex.map} <./prod_brochure.pdf Decrementing ./prod_brochure.pdf (-1)

Deleting ./prod_brochure.pdf ] Creating ./prod_brochure.pdf (0) Reading information on ./prod_brochure.pdf [2 <./prod_bro chure.pdf Decrementing ./prod_brochure.pdf (-1)

Deleting ./prod_brochure.pdf ] ){/usr/local/teTeX/share/texmf/dvips/tetex/f7b6d320.enc} Output written on y.pdf (2 pages, 229447 bytes). Transcript written on y.log.