- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-776 ] Filenames with multiple spaces are not recognized
by noreply＠sarovar.org 17 Apr '07

17 Apr '07

Bugs item #776, was opened at 2007-04-17 22:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106 Category: Primitives Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Nobody (None) Summary: Filenames with multiple spaces are not recognized Initial Comment: $ echo 'hello world\bye' > hello\ \ world.tex $ cat hello\ \ world.tex hello world\bye $ pdftex hello\ \ world.tex This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6) entering extended mode ! I can't find file `"hello world.tex"'. <*> "hello world.tex" Please type another input file name: It seems that pdftex gets the correct name (with two spaces) but it is searching for something different. Regards, Reinhard ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-04-17 23:20 Message: Logged In: YES user_id=1608 It will handle this properly: $ pdftex hello\ \space\ world.tex The problem (of course) is that the tokenizer will fold two (or more) tokens of \catcode 10 into a single one, so you have to prevent tex from seeing two of these in-a-row. It may actually be possible to fix the case where the file is given as a single argument on the commandline, but fixing the general case is unreasonably hard (e.g. \input commands used inside macros), I do not think would be worth the effort and therefore vote for documenting the current behaviour as a known limitation. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106

1 0

[ pdftex-Bugs-776 ] Filenames with multiple spaces are not recognized
by noreply＠sarovar.org 17 Apr '07

17 Apr '07

Bugs item #776, was opened at 2007-04-17 22:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106 Category: Primitives Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Nobody (None) Summary: Filenames with multiple spaces are not recognized Initial Comment: $ echo 'hello world\bye' > hello\ \ world.tex $ cat hello\ \ world.tex hello world\bye $ pdftex hello\ \ world.tex This is pdfTeX, Version 3.141592-1.40.3 (Web2C 7.5.6) entering extended mode ! I can't find file `"hello world.tex"'. <*> "hello world.tex" Please type another input file name: It seems that pdftex gets the correct name (with two spaces) but it is searching for something different. Regards, Reinhard ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=776&group_id=106

1 0

[ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by noreply＠sarovar.org 17 Apr '07

17 Apr '07

Bugs item #772, was opened at 2007-04-13 04:54 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106 Category: web2c Group: v1.40.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Martin Schröder (oneiros) Summary: Option -recorder does not work for Type1 or PK files Initial Comment: Hello, pdfTeX 1.40.3 supports the Web2C feature, enabled by option -recorder. However, it does not record all files, .pfb (Type1) or .pk files are missing. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: texmf.cnf isn't recorded either. ---------------------------------------------------------------------- >Comment By: Heiko Oberdiek (oberdiek) Date: 2007-04-17 13:19 Message: Logged In: YES user_id=1276 Hello, to prevent that it gets lost, a followup of mine in ntg-pdftex mailing list: After further testing (sorry) I found other gaps in file name recording: \pdfximage{<file>} \pdffilesize{<file>} \pdffilemoddate{<file>} \pdffiledump{<file>} \pdfmdfivesum file{<file>} Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=772&group_id=106

1 0

[ pdftex-Bugs-775 ] Build failure on alpha-linux with certain gcc versions
by noreply＠sarovar.org 16 Apr '07

16 Apr '07

Bugs item #775, was opened at 2007-04-16 11:59 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=775&group_id=106 Category: Build process Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Build failure on alpha-linux with certain gcc versions Initial Comment: pdftex fails to build on Linux-alpha with newer gcc versions. This is a known bug in gcc, but it's very obscure and it seems unlikely to be solved soon. Therefore you might consider to apply the patch below as a workaround. Falk Hueffner wrote in the Debian BTS (http://bugs.debian.org/419434) [...] gcc -DHAVE_CONFIG_H -I. -I../../../../texk/web2c/pdftexdir -I.. -I../../../../texk/web2c/pdftexdir/../.. -I.. -I../../../../texk/web2c/pdftexdir/.. -I../.. -I../../../../texk/web2c/pdftexdir/../.. -I../../../libs/md5 -I../../../../texk/web2c/pdftexdir/../../../libs/md5 -I../../../libs/xpdf -I../../../libs/xpdf/.. -I../../../../texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../texk/web2c/pdftexdir/../../../libs/xpdf/.. -I../../../libs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../../texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DpdfTeX -g -O2 -c ../../../../texk/web2c/pdftexdir/writezip.c -o writezip.o ../../../../texk/web2c/pdftexdir/writezip.c: In function 'writezip': ../../../../texk/web2c/pdftexdir/writezip.c:75: error: unrecognizable insn: (insn 139 138 140 9 ../../../../texk/web2c/pdftexdir/writezip.c:54 (set (reg:DI 141) (plus:DI (reg/f:DI 138) (const_int 32768 [0x8000]))) -1 (nil) (nil)) ../../../../texk/web2c/pdftexdir/writezip.c:75: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>. Preprocessed source stored into /tmp/ccKHjfIv.out file, please attach this to your bugreport. make[4]: *** [writezip.o] Error 1 make[4]: Leaving directory `/build/buildd/texlive-bin-2007/build/source/Work/texk/web2c/pdftexdir' (log at http://buildd.debian.org/fetch.cgi?pkg=texlive-bin&arch=alpha&ver=2007-3&st…) The reason is an obscure bug in gcc that only triggers when accessing exactly the 32767th element of a character array. Since I don't know how fix it in gcc and nobody else seems to be working on that, I suggest you apply the following workaround: ---------------------------------------------------------------------- >Comment By: Frank Küster (frank) Date: 2007-04-16 12:04 Message: Logged In: YES user_id=3360 forgot to tick the "attach file" box ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=775&group_id=106

1 0

[ pdftex-Bugs-775 ] Build failure on alpha-linux with certain gcc versions
by noreply＠sarovar.org 16 Apr '07

16 Apr '07

Bugs item #775, was opened at 2007-04-16 11:59 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=775&group_id=106 Category: Build process Group: None Status: Open Resolution: None Priority: 5 Submitted By: Frank Küster (frank) Assigned to: Martin Schröder (oneiros) Summary: Build failure on alpha-linux with certain gcc versions Initial Comment: pdftex fails to build on Linux-alpha with newer gcc versions. This is a known bug in gcc, but it's very obscure and it seems unlikely to be solved soon. Therefore you might consider to apply the patch below as a workaround. Falk Hueffner wrote in the Debian BTS (http://bugs.debian.org/419434) [...] gcc -DHAVE_CONFIG_H -I. -I../../../../texk/web2c/pdftexdir -I.. -I../../../../texk/web2c/pdftexdir/../.. -I.. -I../../../../texk/web2c/pdftexdir/.. -I../.. -I../../../../texk/web2c/pdftexdir/../.. -I../../../libs/md5 -I../../../../texk/web2c/pdftexdir/../../../libs/md5 -I../../../libs/xpdf -I../../../libs/xpdf/.. -I../../../../texk/web2c/pdftexdir/../../../libs/xpdf -I../../../../texk/web2c/pdftexdir/../../../libs/xpdf/.. -I../../../libs/obsdcompat -I../../../libs/obsdcompat/.. -I../../../../texk/web2c/pdftexdir/../../../libs/obsdcompat -I../../../../texk/web2c/pdftexdir/../../../libs/obsdcompat/.. -DpdfTeX -g -O2 -c ../../../../texk/web2c/pdftexdir/writezip.c -o writezip.o ../../../../texk/web2c/pdftexdir/writezip.c: In function 'writezip': ../../../../texk/web2c/pdftexdir/writezip.c:75: error: unrecognizable insn: (insn 139 138 140 9 ../../../../texk/web2c/pdftexdir/writezip.c:54 (set (reg:DI 141) (plus:DI (reg/f:DI 138) (const_int 32768 [0x8000]))) -1 (nil) (nil)) ../../../../texk/web2c/pdftexdir/writezip.c:75: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see <URL:file:///usr/share/doc/gcc-4.1/README.Bugs>. Preprocessed source stored into /tmp/ccKHjfIv.out file, please attach this to your bugreport. make[4]: *** [writezip.o] Error 1 make[4]: Leaving directory `/build/buildd/texlive-bin-2007/build/source/Work/texk/web2c/pdftexdir' (log at http://buildd.debian.org/fetch.cgi?pkg=texlive-bin&arch=alpha&ver=2007-3&st…) The reason is an obscure bug in gcc that only triggers when accessing exactly the 32767th element of a character array. Since I don't know how fix it in gcc and nobody else seems to be working on that, I suggest you apply the following workaround: ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=775&group_id=106

1 0

[ pdftex-Bugs-774 ] UniqueID in subsetted Type1 fonts
by noreply＠sarovar.org 15 Apr '07

15 Apr '07

Bugs item #774, was opened at 2007-04-15 23:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106 Category: Fonts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhard Kotucha (reinhard) Assigned to: Hartmut Henkel (hhenkel) Summary: UniqueID in subsetted Type1 fonts Initial Comment: The currant version of pdftex removes the UniqueID from the font dictionary when a subset of a Type1 font is included. However, there is still a UniqueID in the Private dictionary which should be removed too. >From the PostScript Language Reference Manual (p. 336): > When you copy a font dictionary for the purpose of > creating a modified font, you should not copy the > UniqueID or XUID entry. As an exception to this > general rule, it is acceptable (and preferable) to > retain the original UniqueID or XUID entry if > the only modified entries are FontName, FontInfo, > FontMatrix, or Encoding, because those changes do not > affect the glyphs’ appearance or metrics. Regards, Reinhard ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=774&group_id=106

1 0

Re: [NTG-pdftex] [ pdftex-Bugs-772 ] Option -recorder does not work for Type1 or PK files
by Akira Kakuto 15 Apr '07

15 Apr '07

Hi Heiko, > Bugs item #772, was opened at 2007-04-13 04:54 > pdfTeX 1.40.3 supports the Web2C feature,enabled by option -recorder. > However, it does not record all files,.pfb (Type1) or .pk files are missing. > Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> > PS: texmf.cnf isn't recorded either. I think texmf.cnf is not read by using open_input also in the case of the other TeX programs. Best regards, Akira --- writet1.c.orig Wed Dec 27 08:37:36 2006 +++ writet1.c Sun Apr 15 11:00:09 2007 @@ -921,10 +921,18 @@ static boolean t1_open_fontfile(const char *open_name_prefix) { ff_entry *ff; - ff = check_ff_exist(fd_cur->fm->ff_name, is_truetype(fd_cur->fm)); - if (ff->ff_path != NULL) - t1_file = xfopen(cur_file_name = ff->ff_path, FOPEN_RBIN_MODE); - else { + boolean is_tt = is_truetype (fd_cur->fm); + ff = check_ff_exist(fd_cur->fm->ff_name, is_tt); + if (ff->ff_path != NULL) { + cur_file_name = ff->ff_path; + if (nameoffile) free (nameoffile); + nameoffile = (char *)malloc (strlen (cur_file_name) + 2); + (void)strcpy (nameoffile + 1, cur_file_name); + if (is_tt) + open_input (&t1_file, kpse_truetype_format, FOPEN_RBIN_MODE); + else + open_input (&t1_file, kpse_type1_format, FOPEN_RBIN_MODE); + } else { set_cur_file_name(fd_cur->fm->ff_name); pdftex_warn("cannot open Type 1 font file for reading"); return false; --- writet3.c.orig Wed Dec 27 08:37:36 2006 +++ writet3.c Sun Apr 15 11:02:10 2007 @@ -197,7 +197,13 @@ cur_file_name = NULL; return false; } - t3_file = xfopen(name, FOPEN_RBIN_MODE); + if (nameoffile) free (nameoffile); + nameoffile = (char *)malloc (strlen (name) + 2); + strcpy (nameoffile + 1, name); + if (!open_input (&t3_file, kpse_pk_format, FOPEN_RBIN_MODE)) { + pdftex_warn ("missing pk font %s.", name); + return false; + } t3_image_used = true; is_pk_font = true; tex_printf(" <%s", (char *) name);

2 1

Re: [NTG-pdftex] [pdftex] Font (embedding) problem
by Reinhard Kotucha 14 Apr '07

14 Apr '07

Hi, I now added pdftex, NTG-pdftex, and Eddie to the CC. For people who did not follow the thread on the pdftex mailing list, here is a short summary: Marcel created some subsets of an OTF font using lcdf typetools. One subset used normal figures, one used oldstyle figures and one used superscript figures. His printer produced wrong output. I examined the output files produced by pdftex: All the subsets used the same encoding scheme, the glyph names had been /one, /two, and /three in all subsets, the /UniqueID is the same in all subsets. The only difference was /FontName since an arbitrary string had been prepended to the original /FontName. It turned out that Marcel's printer ignores /FontName and entirely depends on the /UniqueID. I converted the three subsets to PFA and wrote a small test file and even Ghostscript (-sDEVICE=X11alpha) produced wrong output. See: http://ms25.ath.cx/testfonts.ps It works with gs if you comment out the /UniqueID in testfonts.ps but this seems not to be sufficient for Marcel's printer because: >>>>> "Marcel" == Marcel Korpel <marcel.lists(a)gmail.com> writes: > On 04/04/07, Reinhard Kotucha <reinhard.kotucha(a)web.de> wrote: >> The current release (1.40.3) does this already. At least it >> removes the first occurrence of the UniqueID. But there is still >> a UniqueID in the /Private dictionary. Maybe it should be >> removed too. I'm quite confident that no interpreter looks for a >> UniqueID in the /Private dictionary. > Well, at least the mentioned Océ printer seems to use it. When I > only remove the first instance of the /UniqueID, the bug pops up > again... In my opinion it is wrong to ignore /FontName. But on the other hand I think that it is also wrong *not* to delete the /UniqueID when a subset of a font is created. I don't know what the Adobe reference manuals say, the nasty things are in the TechNotes, but it seems that developers of PS interpreters interpret the specs slightly different anyway. Though I think that the /UniqueID is helpful to distinguish between Adobe Courier and IBM Courier (shipped with X11), I now come to the conclusion that it causes more trouble than it helps. I don't think that it's bad that a font provides a /UniqueID. But it is probably quite appropriate to remove it when a subset is created. The current release of pdftex deletes the /UniqueID from the font dictionary but not the instance in the /Private dictionary. But certainly it should. I also think that lcdf typetools should remove the /UniqueID if a font is altered. 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. ----------------------------------------------------------------------------

3 4

problem when using package color with floats
by Bintu Vasudevan 13 Apr '07

13 Apr '07

Hi when i redefine the macro used for floats (including figures and tables) so that single spacing is used. My tex file compile and as work fine. But when i want to usepackage{color} is hangs througing with message: ============================================= ! Too many }'s. \color@endbox ->\color@endgroup \egroup l.39 \end{figure} ? ============================================== Here is Redefined the macro defined ----------------------------------------------------------------------------------------------------- % (Note \def\figure{\@float{figure}set single spacing} doesn't work % because figure has an optional argument) \def\@xfloat#1[#2]{\ifhmode \@bsphack\@floatpenalty -\@Mii\else \@floatpenalty-\@Miii\fi\def\@captype{#1}\ifinner \@parmoderr\@floatpenalty\z@ \else\@next\@currbox\@freelist{\@tempcnta\csname ftype@#1\endcsname \multiply\@tempcnta\@xxxii\advance\@tempcnta\sixt@@n \@tfor \@tempa :=#2\do {\if\@tempa h\advance\@tempcnta \@ne\fi \if\@tempa t\advance\@tempcnta \tw@\fi \if\@tempa b\advance\@tempcnta 4\relax\fi \if\@tempa p\advance\@tempcnta 8\relax\fi }\global\count\@currbox\@tempcnta}\@fltovf\fi \global\setbox\@currbox\vbox\bgroup \def\baselinestretch{1}\@normalsize \boxmaxdepth\z@ \hsize\columnwidth \@parboxrestore} ----------------------------------------------------------------------------------------------------- can some body help in this case. Thanks in Advance bintu --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.

2 1

Re: [NTG-pdftex] [pdftex] Font (embedding) problem
by Thanh Han The 13 Apr '07

13 Apr '07

yes. At least for me. Regards, Thanh On Thu, Apr 12, 2007 at 07:21:14AM -0700, Eddie Kohler wrote: > Fonts produced by lcdf-typetools usually work fine with pdftex!... ?? > > Eddie > > > Marcel Korpel wrote: > > On 12/04/07, Eddie Kohler <kohler(a)cs.ucla.edu> wrote: > >> How did Marcel create the subsets? I imagine that pdftex was > >> responsible for the real subsetting; that the lcdf-typetools simply > >> created the initial font. > > > > No, I didn't use lcdf-tools, it wasn't an OTF font. I was wrong in my > > initial mail. When using a different font encoding with the same PFB > > fle (produced by lcdf-tools), everything was ok. > > > > I created the subsets using Fontforge, manually, and put the right > > characters in the right positions, so I could use them with pdfTeX. > > > > Sorry for this confusion caused, I was not wholly clear. > > > > Regards, > > Marcel > _______________________________________________ > pdftex mailing list > pdftex(a)tug.org > http://tug.org/mailman/listinfo/pdftex

1 0