April 2004 - ntg-pdftex - NTG Mailing Lists

1.20a-rc2
by Martin Schröder 27 Apr '04

27 Apr '04

Hi, #4712 is 1.20a-rc2. Once I can figure out how to make a release with sarovar, the archive will show up there. 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 4

Re: [NTG-pdftex] 1.20a-rc2
by Akira Kakuto 26 Apr '04

26 Apr '04

>It's finally there (will be moved to beta): >http://sarovar.org/download.php/285/pdftex-1.20a-rc2.tar.bz2 Olaf has changed tex.ch in his source because terminal inputs are not recognized for the prompt '?'. Best regards Akira --- tex.ch Sat Apr 17 06:47:39 2004 +++ /wk/752/texk/web2c/tex.ch Thu Apr 22 18:31:13 2004 @@ -965,7 +965,7 @@ @x [5.71] encTeX - native buffer printing if last<>first then for k:=first to last-1 do print(buffer[k]); @y -while first < last do begin print_buffer(first) end; +k:=first; while k < last do begin print_buffer(k) end; @z @x [6.73] l.1732 - Add unspecified_mode.

2 1

Re: ntg-pdftex digest, Vol 1 #155 - 1 msg
by Akira Kakuto 23 Apr '04

23 Apr '04

> Yes; 1.20a here returns the same results. > > 1.11a gives > > pdfinfo xx.pdf > Creator: TeX > Producer: pdfTeX-1.11a > CreationDate: Thu Apr 8 15:15:45 2004 > Tagged: no > Pages: 1 > Encrypted: no > Page size: 595.276 x 841.89 pts > File size: 5783 bytes > Optimized: no > PDF version: 1.4 > > pdfinfo x1.pdf > Creator: TeX > Producer: pdfTeX-1.11a > CreationDate: Thu Apr 8 15:15:55 2004 > Tagged: no > Pages: 1 > Encrypted: no > Page size: 714.331 x 1010.27 pts > File size: 5783 bytes > Optimized: no > PDF version: 1.4 > > Which certainly is different (and correct). > > I'm confused and suspect some problem with pdftexconfig.tex ... This is fixed by the following patch: Best regards, Akira --- pdftex.ch.orig Mon Mar 22 19:57:04 2004 +++ pdftex.ch Fri Apr 09 22:39:23 2004 @@ -3607,12 +3607,6 @@ ensure_pdf_open; check_and_set_pdfoptionpdfminorversion; prepare_mag; -if (mag <> 1000) and (mag <> 0) then begin - dimen_par(pdf_h_origin_code) := round_xn_over_d(dimen_par(pdf_h_origin_code), 1000, mag); - dimen_par(pdf_v_origin_code) := round_xn_over_d(dimen_par(pdf_v_origin_code), 1000, mag); - dimen_par(pdf_page_height_code) := round_xn_over_d(dimen_par(pdf_page_height_code), 1000, mag); - dimen_par(pdf_page_width_code) := round_xn_over_d(dimen_par(pdf_page_width_code), 1000, mag) -end; fixed_decimal_digits := fix_int(pdf_decimal_digits, 0, 4); min_bp_val := divide_scaled(one_hundred_bp, ten_pow[fixed_decimal_digits + 2], 0);

4 14

papersiz.c obsolete
by Hartmut Henkel 15 Apr '04

15 Apr '04

papersiz.c seems to be obsolete; only provided myato*() to config.c. Can be removed, see also /* papersiz.c */ stuff in ptexlib.h. Regards, Hartmut

2 1

Re: pdftex 1.20a: weird magstep problem
by Martin Schröder 08 Apr '04

08 Apr '04

On 2004-04-07 11:04:17 +0200, Hartmut Henkel wrote: > while pdfTeXing business travel expenses here, things run differently > than before, I get the text shifted, and page dimensions come out wrong, > old files give now wrong results. See example xx.tex: > > \magnification\magstep1 > \pdfpagewidth=210truemm > \pdfpageheight=297truemm > Hi > \bye > > Do you also get > > hahe@hahepc:~$ pdfinfo xx.pdf > Creator: TeX > Producer: pdfTeX-1.20a > CreationDate: Wed Apr 7 10:53:02 2004 > Tagged: no > Pages: 1 > Encrypted: no > Page size: 496.063 x 701.575 pts > File size: 4303 bytes > Optimized: no > PDF version: 1.4 > > ? Shouldn't this be A4? And > > \magnification\magstep1 > \pdfpagewidth=210mm > \pdfpageheight=297mm > Hi > \bye > > gives > > Creator: TeX > Producer: pdfTeX-1.20a > CreationDate: Wed Apr 7 10:55:48 2004 > Tagged: no > Pages: 1 > Encrypted: no > Page size: 595.276 x 841.89 pts (A4) > File size: 4304 bytes > Optimized: no > PDF version: 1.4 > > which _is_ A4. Yes; 1.20a here returns the same results. 1.11a gives > pdfinfo xx.pdf Creator: TeX Producer: pdfTeX-1.11a CreationDate: Thu Apr 8 15:15:45 2004 Tagged: no Pages: 1 Encrypted: no Page size: 595.276 x 841.89 pts File size: 5783 bytes Optimized: no PDF version: 1.4 > pdfinfo x1.pdf Creator: TeX Producer: pdfTeX-1.11a CreationDate: Thu Apr 8 15:15:55 2004 Tagged: no Pages: 1 Encrypted: no Page size: 714.331 x 1010.27 pts File size: 5783 bytes Optimized: no PDF version: 1.4 Which certainly is different (and correct). I'm confused and suspect some problem with pdftexconfig.tex ... 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

sarovar
by Martin Schröder 06 Apr '04

06 Apr '04

Thanh, I see that you have already set up a pdftex project at sarovar. Please add me to the project (user oneiros); we should use it at least for tracking bugs, patches and feature requests. TIA 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 1

Re: pdftex, Base-14 Fonts
by Martin Schröder 05 Apr '04

05 Apr '04

On 2004-04-03 12:20:50 +0200, Hartmut Henkel wrote: > Until now, the base-14 fonts are _never_ embedded, unless one tweaks the > BaseName entry in the 2nd mapline field. These BaseName entries are > compared against a list of the base-14 fontnames, and if they match one > of these, the fontfile is ignored. > > I have changed this check in a small experiment so that the following > happens: > > If a mapline contains a BaseName from the base-14 set, e. g. > Helvetica, the further treatment depends on whether a fontfile name is > given or not: If the fontfile name (e. g. <phvr8a.pfb) is there, the > base-14 font (e. g. Helvetica) will be embedded. If it is not there, it > is silently treated as usual base-14 font (nothing will be embedded), > and the text will be displayed from Acroread's own font version. > > If there is a mapline with a BaseName not from the base-14 set, and no > fontfile is given, the usual warning is issued. > > So one can decide by telling or omitting a fontfile name, whether a font > from the base-14 set is embedded or not (which seems to me a rather > natural way). No new switch or primitive would be needed. And the usual > behaviour could be reached by editing the file pdftex.map, or by making > a small modification to the updmap script. > > I have separated the flag is_basefont() and is_included() in file > mapfile.c, so that one now can distinguish between all these cases. > > Attached is a tgz-file with the patch to mapfile.c, and a some test > files, which also exercise a few cases of embedding things. Just rough > stuff, lots of more tests would be needed to fully understand all > embedding cases. What do you think? Sounds very interesting and like a very natural user interface. But i think it's much too late for 1.20a. 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 1

map files
by Hans Hagen 05 Apr '04

05 Apr '04

Hi, I just noticed that as soon as pdftex does a pdf inclusion it needs to know the map file(s); on the other hand, for text the map file is only needed as soon as the page is shipped out. 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 -------------------------------------------------------------------------

1 0