- ntg-pdftex - NTG Mailing Lists

Re: [NTG-pdftex] 1.30.0-rc4
by Akira Kakuto 23 Jul '05

23 Jul '05

> Your -etex switch patch looks reasonable, though I might make some > changes (variable names &c) when I check in the code. I forgot to consider aleph (eobase.ch and eoext.ch). Please check in also those files. Thanks, -- Akira Kakuto

1 0

Re: [NTG-pdftex] no etex while dump
by Akira Kakuto 22 Jul '05

22 Jul '05

> To summarize; under bash (linux or cygwin) environment and gcc as a > builder, things are consistent, although seems to be mysterious. To be > on safe side, a star should be quoted. Under windows the behaviour is > environment/compiler dependent. Binaries made by M$ compiler behaves > quite well; the star is not expanded anyhow by shell and is passed to > TeX as is. Consequently, it CAN'T be quoted with backslash, since TeX > reports `Undefined control sequence \*' then. Windows binaries made by > gcc under cyg environment works like those under linux. That is the > whole mystery. -etex commandline option will fix the inconsistency. diff -Nur web2c-orig/etexdir/etex.ch web2c/etexdir/etex.ch --- web2c-orig/etexdir/etex.ch Wed Oct 13 06:29:47 2004 +++ web2c/etexdir/etex.ch Sat Jul 23 00:36:24 2005 @@ -3051,10 +3051,11 @@ is a run-time switch. @<Enable \eTeX, if requested@>= -@!init if (buffer[loc]="*")and(format_ident=" (INITEX)") then +@!init if ((buffer[loc]="*")or etex_extension_p)and(format_ident=" (INITEX)") then begin no_new_control_sequence:=false; @<Generate all \eTeX\ primitives@>@; - incr(loc); eTeX_mode:=1; {enter extended mode} + if (buffer[loc]="*") then incr(loc); + eTeX_mode:=1; {enter extended mode} @<Initialize variables for \eTeX\ extended mode@>@; end; tini@;@/ @@ -3094,6 +3095,7 @@ @<Glob...@>= @!eTeX_mode: 0..1; {identifies compatibility and extended mode} +@!etex_extension_p : boolean; @ @<Initialize table entries...@>= eTeX_mode:=0; {initially we are in compatibility mode} diff -Nur web2c-orig/lib/texmfmp.c web2c/lib/texmfmp.c --- web2c-orig/lib/texmfmp.c Tue Jul 05 20:16:44 2005 +++ web2c/lib/texmfmp.c Sat Jul 23 00:51:48 2005 @@ -778,6 +778,9 @@ { "no-shell-escape", 0, &shellenabledp, -1 }, { "debug-format", 0, &debugformatfile, 1 }, { "src-specials", 2, 0, 0 }, +#if defined (eTeX) || defined (pdfeTeX) + { "etex", 0, &etexextensionp, 1 }, +#endif #endif /* TeX */ #if defined (TeX) || defined (MF) || defined (MP) { "file-line-error-style", 0, &filelineerrorstylep, 1 }, diff -Nur web2c-orig/texmfmp-help.h web2c/texmfmp-help.h --- web2c-orig/texmfmp-help.h Sun Aug 29 06:29:38 2004 +++ web2c/texmfmp-help.h Sat Jul 23 00:41:45 2005 @@ -93,6 +93,7 @@ " If no arguments or options are specified, prompt for input.", "", "-enc enable encTeX extensions such as \\mubyte", + "-etex enable e-TeX extensions in INITEX", "[-no]-file-line-error disable/enable file:line:error style messages", "-fmt=FMTNAME use FMTNAME instead of program name or a %& line", "-halt-on-error stop processing at the first error", @@ -408,6 +409,7 @@ " If no arguments or options are specified, prompt for input.", "", "-enc enable encTeX extensions such as \\mubyte", + "-etex enable e-TeX extensions in INITEX", "[-no]-file-line-error disable/enable file:line:error style messages", "-fmt=FMTNAME use FMTNAME instead of program name or a %& line", "-halt-on-error stop processing at the first error",

2 1

changes in forthcomming release
by The Thanh Han 22 Jul '05

22 Jul '05

Hi, I have applied most of patches and suggestions from Hartmut. There are still a few pending issues: 1) while we are renaming some promitives to be consistent, would it be better to change the following as well: pdfoptionpdfminorversion -> pdfminorversion pdfoptionalwaysusepdfpagebox -> pdfforcepagebox pdfoptionpdfinclusionerrorlevel -> ??? 2) what about moving everything from pdfxtex to pdftex and remove pdfxtex? 3) should the pkmode and microinterval patches be in as well? Martin, can you please wait for a few days, I want to make another snapshot this week. Thanh

5 7

no etex while dump
by Pawel Jackowski 22 Jul '05

22 Jul '05

On 1.30-rc2 I made the following z.tex file: \catcode`\{=1 \catcode`\}=2 \edef\z{\the\eTeXversion} \dump Then I hit pdfetex -ini *z.tex and got This is pdfeTeXk, Version 3.141592-1.30.0-rc2-2.2 (Web2C 7.5.4) (INITEX) 22 JUL 2005 00:22 \write18 enabled. %&-line parsing enabled. **z.tex (./z.tex ! Undefined control sequence. l.3 \edef\z{\the\eTeXversion } Clues? Sorry, for the moment I can't try on rc3. BR, -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

6 12

Re: [NTG-pdftex] no etex while dump
by Akira Kakuto 22 Jul '05

22 Jul '05

> pdfetex --ini '*z' works. > pdfetex --ini '*z.tex' fails. > > I cannot understand the reason. It was a funny shell effect. Many thanks to Hartmut. -- Akira Kakuto

1 0

Re: [NTG-pdftex] no etex while dump
by Akira Kakuto 22 Jul '05

22 Jul '05

> Sorry. I was wrong. > pdfeinitex \*z.tex worked. Correction: pdfetex --ini '*z' works. pdfetex --ini '*z.tex' fails. I cannot understand the reason. -- Akira Kakuto

1 0

Re: [NTG-pdftex] no etex while dump
by Akira Kakuto 22 Jul '05

22 Jul '05

> It seemes that } is forbidden after \the in the > case of \edef: > > pdfetex --ini '*z.tex' > This is pdfeTeX, Version 3.141592-1.30.0-rc3-2.2 (Web2C 7.5.5) (INITEX) > (./z.tex > ! Undefined control sequence. > l.3 \edef\z{\the\eTeXversion > } > ? > ! You can't use `end-group character }' after \the. > l.3 \edef\z{\the\eTeXversion} Sorry. I was wrong. pdfeinitex \*z.tex worked. -- Akira Kakuto

1 0

Re: [NTG-pdftex] no etex while dump
by Akira Kakuto 22 Jul '05

22 Jul '05

> This is pdfeTeXk, Version 3.141592-1.30.0-rc2-2.2 (Web2C 7.5.4) (INITEX) > 22 JUL 2005 00:22 > \write18 enabled. > %&-line parsing enabled. > **z.tex > (./z.tex > ! Undefined control sequence. > l.3 \edef\z{\the\eTeXversion > } > Clues? Sorry, for the moment I can't try on rc3. It seemes that } is forbidden after \the in the case of \edef: pdfetex --ini '*z.tex' This is pdfeTeX, Version 3.141592-1.30.0-rc3-2.2 (Web2C 7.5.5) (INITEX) (./z.tex ! Undefined control sequence. l.3 \edef\z{\the\eTeXversion } ? ! You can't use `end-group character }' after \the. l.3 \edef\z{\the\eTeXversion} -- Akira Kakuto

1 0

Re: [NTG-pdftex] no etex while dump
by Pawel Jackowski 22 Jul '05

22 Jul '05

> Hartmut > it works also here without quote even in rc3! Same bash. I don't > understand this. Needs checking... I haven't noticed this behaviour on rc1. Give me some time, I will try to compile rc1 once again and check with the same conditions. > Taco: > Are you sure? Yes I am sure that something differs depending on something :) I'm not sure if it is a bug. I'm sure that the same command (without quoted *) on the same shell works differently on pdfTeX 1.20a and pdfTeX 1.30.0-rc2. Meybe it is a question of compiler? One was compiled under M$ Visual C, the second under gcc. Checking... > Hans: > indeed; it's a feature request -) I always assume I don't know something important :) Anyway, I strongly support this request. -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

2 2

[ pdftex-Bugs-359 ] pdftex generates errors when it does not have to - eg \pdfinfo
by noreply＠sarovar.org 22 Jul '05

22 Jul '05

Bugs item #359, was opened at 2005-05-30 19:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=359&group_id=106 Category: None >Group: v1.21a >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: pdftex generates errors when it does not have to - eg \pdfinfo Initial Comment: The following submitted on behalf of Jonathan Fine: pdftex generates errors when it does not have to. This fault prevents the build of Python docs on some platforms. The fix may be to remove the error-generating code· For more details, see my posting to comp.text.tex. Google link: <http://groups-beta.google.com/group/comp.text.tex/msg/4b4842202ce88cda?hl=en> Copy and paste ============== There is, in my opinion, a problem with pdftex. (This is not to say that the macros used could not be improved.) pdftex exits on \pdfinfo error. TeX does not exit on error. == $ pdftex This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5) **\pdfoutput 0 {/usr/share/texmf/pdftex/config/pdftex.cfg} *\pdfinfo pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. <*> \pdfinfo No pages of output. Transcript written on texput.log. == The present semantics of \pdfinfo are confused. For example, I _can_ use \pdfinfo and generate dvi! I just have to be a bit sneaky. == $ pdftex This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5) **\pdfoutput 1 {/usr/share/texmf/pdftex/config/pdftex.cfg} *\pdfinfo {} *\pdfoutput 0 *\shipout\hbox{} [1] *\end Output written on texput.dvi (1 page, 128 bytes). == Here, if pdf is not being generated, pdfinfo is ignored. Suppose the semantics of \pdfinfo were something like: \pdfinfo{ ... } Stores information that is written to the PDF file, if pdftex generates a PDF file. Otherwise ignored. Then the error that prompted this thread would not have occurred. -- ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-22 11:10 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-05-30 20:05 Message: Logged In: YES user_id=1608 Relevant bit of code: procedure check_pdfoutput(s: str_number); begin if pdf_output <= 0 then begin print_nl("pdfTeX error (ext1): "); print(s); print(" used while \pdfoutput is not set"); succumb; end; end The fastest resolution, of course, is to change the test to "pdf_output < 0" so that the error is also generated in dvi processing mode. But Jonathan's proposal is also valid, at least for mode-independant commands like \pdfinfo. Or maybe generate a normal TeX error message? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=359&group_id=106

1 0

[ pdftex-Patches-391 ] Extending \pdfliteral
by noreply＠sarovar.org 22 Jul '05

22 Jul '05

Patches item #391, was opened at 2005-07-17 23:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=391&group_id=106 Category: Literals Group: v1.30.0 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Extending \pdfliteral Initial Comment: see ntg-pdftex list 17 Jul 2005 and README inside pdfliteral.tgz ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-22 11:09 Message: Logged In: YES user_id=421 This has been included in version 1.30.0 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=391&group_id=106

1 0

merging pdftex sources into a single master file
by The Thanh Han 21 Jul '05

21 Jul '05

Hi, there were some disscusions on whether we shoule merge pdftex sources into a single master file pdftex.web. There are many pros and cons: Pros: will make life of us pdftex developers easier, and faster development of pdftex Cons: someone has to do the job merging pdftex with other extensions like etex, enctex or mltex. >From my side I would be happier with a single master file pdftex.web, but I would like to learn what impacts it can has. Thanh

3 2

Extensions: \pdf$foo or \$foo?
by Martin Schröder 21 Jul '05

21 Jul '05

Hi, at LinuxTag in Karlsruhe I met with Heiko and Hartmut and we talked about pdfTeX. One point discussed was namespace: Till lately most new primitives of pdfTeX startet with \pdf (\efcode, \lpcode and \rpcode are the only exceptions), but now we have some patches that add primitives that don't start with \pdf (\leftmarginkern, \rightmarginkern, \elapsedtime, \resettime, \random). I'm reluctant to use the non-\pdf-namespace and think it better to stay in \pdf. Comments? Best regards Martin PS: One can always \let \pdf$foo to \$foo in *.ini -- http://www.tm.oneiros.de

7 35

Patch 391: Extending \pdfliteral
by Hartmut Henkel 19 Jul '05

19 Jul '05

Currently the \pdfliteral can be used with "direct" option, or without. In "direct" mode, the \pdfliteral text goes directly into the stream, wherever, without any coordinate transform. Without "direct" there is always an ET, and a transform. It seems that Acrobat does not allow grouping q...Q inside BT...ET sections (xpdf tolerates it). There is currently no way to guarantee that a literal text does not end up in a BT...ET section without using the plain \pdfliteral {} mode (without "direct"). But then one has the matrix transform, which precludes grouping; well, here is a funny counter-example: \pdfcompresslevel=0 \newbox\marbox \setbox\marbox\hbox{\qquad Hello} A% \pdfliteral {q}% \rlap{% \box\marbox }% \pdfliteral {Q}% B \bye This gives: BT /F1 9.9626 Tf 91.9253 759.9271 Td[(A)]TJ ET 1 0 0 1 99.3973 759.9271 cm q 1 0 0 1 -99.3973 -759.9271 cm BT /F1 9.9626 Tf 119.3226 759.9271 Td[(Hello)]TJ ET 1 0 0 1 99.3973 759.9271 cm Q 1 0 0 1 -99.3973 -759.9271 cm BT /F1 9.9626 Tf 99.3973 759.9271 Td[(B)]TJ 204.112 -654.7472 Td[(1)]TJ ET It even comes out right :-) But when one could guarantee that the grouping does not end up in a BT...ET section, one could have such a simpler PDF output instead: BT /F1 9.9626 Tf 91.9253 759.9271 Td[(A)]TJ ET q BT /F1 9.9626 Tf 119.3226 759.9271 Td[(Hello)]TJ ET Q BT /F1 9.9626 Tf 99.3973 759.9271 Td[(B)]TJ 204.112 -654.7472 Td[(1)]TJ ET That's what the new "et" option of the appended tiny experimental patch does; it forces an ET if required, but without transform. In the patch also the internal literal() function interface is slightly changed to make a little more transparent what happens. With this patch it seems to be roughly like the following: 1. any color change without q/Q grouping just put into \pdfliteral direct {}. No transform will happen, resulting in minimum amount of PDF code. And this should hopefully be safe after bug 389 has gone. 2. for grouping around TeX stuff use pairs of \pdfliteral et {}, or \special{pdf:et:...}. Grouping will be done outside BT...ET, no transform will happen. 3. for positioning of raw PDF graphics at the current point put it into \pdfliteral {} as usual. 4. for positioning of raw PDF graphics with absolute positioning on the page relative to its lower left corner from everywhere on the page put it into \pdfliteral et {}. This is low-level stuff, should not interfere with a color stack. Would such an "et" option have its use? Regards, Hartmut

3 9

character attribute
by The Thanh Han 19 Jul '05

19 Jul '05

Hi, currently a character node in tex has the only attribute, ie the associated font. I m wondering whether it makes sense to replace this attribute (font) by a pointer to some data structure representing a set of attributes. This way we can add further attributes of a character without messing up around the sources. Such attributes can be: font, color, location in tex sources, next bytes of a utf8 sequence etc. How to you guys see it? Thanh

4 5

Re: [NTG-pdftex] pdftex maintenance
by The Thanh Han 18 Jul '05

18 Jul '05

ah indeed it was my fault not to update the server name. Many thanks to Akira. But I still feel that it is better to leave the maintenance to Martin only. Regards, Thanh On Mon, Jul 18, 2005 at 07:04:02AM +0900, Akira Kakuto wrote: > Hi Thanh, > > > I no longer have access to the texlive perforce server (port > > 1666 blocked), ... > > Do you know p4 server machine has been changed? > > old sun.dante.de:1666 > new texlive.dante.de:1666 ( alias of comedy.dante.de:1666 ) > > If port 1666 is blocked in your site, the above is useless, sorry. > > -- > Akira Kakuto >

1 0

pdftex maintenance
by The Thanh Han 17 Jul '05

17 Jul '05

Hi all, I no longer have access to the texlive perforce server (port 1666 blocked), hence I think this is the moment to make an official request: that is from now only Martin will be responsible for sources maintance and tracking bugs/patches/feature requests. If I make any changes, I will submit my changes in the same way like Hartmut, Taco and Heiko have been doing. How do you see it? Regards, Thanh

3 2

[ pdftex-Patches-391 ] Extending \pdfliteral
by noreply＠sarovar.org 17 Jul '05

17 Jul '05

Patches item #391, was opened at 2005-07-17 23:48 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=391&group_id=106 Category: Literals Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Nobody (None) Summary: Extending \pdfliteral Initial Comment: see ntg-pdftex list 17 Jul 2005 and README inside pdfliteral.tgz ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=391&group_id=106

1 0

[ pdftex-Bugs-389 ] Spacing Bug with \pdfliteral direct
by noreply＠sarovar.org 15 Jul '05

15 Jul '05

Bugs item #389, was opened at 2005-07-14 08:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=389&group_id=106 Category: Literals Group: v1.30.0 >Status: Closed >Resolution: Fixed >Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: Spacing Bug with \pdfliteral direct Initial Comment: "\pdfliteral direct" screws up spacing. Hans found it. Therefore one has to use the non-direct variant e. g. for changing color in text, which results in tedious transforms. The trivial patch seems to solve this. Now it's possible to define color "direct". See the test.pdf file. Actually i don't understand at all what the patch does, but it seemed to be the only place where the literal interferes with position calculations. It seems that the patch does not mangle the horizontal positioning calculation; see the placement of the \vrule after the ET, which is independent from whether \pdfliteral direct is used or not. Rough patch. Tests welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-15 15:25 Message: Logged In: YES user_id=421 This has been fixed in 1.30.0 ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-07-14 10:28 Message: Logged In: YES user_id=1608 I did some extra tests with spaces around the grey text, and it output turned out ok. I don't understand this trickery with pdf_first_space_corr at all, but since it seems to work i'm reluctant to spend an indeterminate amount of time on discovering the intent of it. Patch looks good, afaict. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=389&group_id=106

2 1

[ pdftex-Bugs-359 ] pdftex generates errors when it does not have to - eg \pdfinfo
by noreply＠sarovar.org 15 Jul '05

15 Jul '05

Bugs item #359, was opened at 2005-05-30 19:51 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=359&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: pdftex generates errors when it does not have to - eg \pdfinfo Initial Comment: The following submitted on behalf of Jonathan Fine: pdftex generates errors when it does not have to. This fault prevents the build of Python docs on some platforms. The fix may be to remove the error-generating code· For more details, see my posting to comp.text.tex. Google link: <http://groups-beta.google.com/group/comp.text.tex/msg/4b4842202ce88cda?hl=en> Copy and paste ============== There is, in my opinion, a problem with pdftex. (This is not to say that the macros used could not be improved.) pdftex exits on \pdfinfo error. TeX does not exit on error. == $ pdftex This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5) **\pdfoutput 0 {/usr/share/texmf/pdftex/config/pdftex.cfg} *\pdfinfo pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set. <*> \pdfinfo No pages of output. Transcript written on texput.log. == The present semantics of \pdfinfo are confused. For example, I _can_ use \pdfinfo and generate dvi! I just have to be a bit sneaky. == $ pdftex This is pdfTeX, Version 3.14159-1.10b (Web2C 7.4.5) **\pdfoutput 1 {/usr/share/texmf/pdftex/config/pdftex.cfg} *\pdfinfo {} *\pdfoutput 0 *\shipout\hbox{} [1] *\end Output written on texput.dvi (1 page, 128 bytes). == Here, if pdf is not being generated, pdfinfo is ignored. Suppose the semantics of \pdfinfo were something like: \pdfinfo{ ... } Stores information that is written to the PDF file, if pdftex generates a PDF file. Otherwise ignored. Then the error that prompted this thread would not have occurred. -- ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2005-05-30 20:05 Message: Logged In: YES user_id=1608 Relevant bit of code: procedure check_pdfoutput(s: str_number); begin if pdf_output <= 0 then begin print_nl("pdfTeX error (ext1): "); print(s); print(" used while \pdfoutput is not set"); succumb; end; end The fastest resolution, of course, is to change the test to "pdf_output < 0" so that the error is also generated in dvi processing mode. But Jonathan's proposal is also valid, at least for mode-independant commands like \pdfinfo. Or maybe generate a normal TeX error message? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=359&group_id=106

4 5

[ pdftex-Bugs-389 ] Spacing Bug with \pdfliteral direct
by noreply＠sarovar.org 14 Jul '05

14 Jul '05

Bugs item #389, was opened at 2005-07-14 08:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=389&group_id=106 Category: Literals Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: Spacing Bug with \pdfliteral direct Initial Comment: "\pdfliteral direct" screws up spacing. Hans found it. Therefore one has to use the non-direct variant e. g. for changing color in text, which results in tedious transforms. The trivial patch seems to solve this. Now it's possible to define color "direct". See the test.pdf file. Actually i don't understand at all what the patch does, but it seemed to be the only place where the literal interferes with position calculations. It seems that the patch does not mangle the horizontal positioning calculation; see the placement of the \vrule after the ET, which is independent from whether \pdfliteral direct is used or not. Rough patch. Tests welcome. Regards, Hartmut ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2005-07-14 10:28 Message: Logged In: YES user_id=1608 I did some extra tests with spaces around the grey text, and it output turned out ok. I don't understand this trickery with pdf_first_space_corr at all, but since it seems to work i'm reluctant to spend an indeterminate amount of time on discovering the intent of it. Patch looks good, afaict. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=389&group_id=106

1 0

[ pdftex-Bugs-389 ] Spacing Bug with \pdfliteral direct
by noreply＠sarovar.org 14 Jul '05

14 Jul '05

Bugs item #389, was opened at 2005-07-14 08:34 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=389&group_id=106 Category: Literals Group: v1.30.0 Status: Open Resolution: None Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: Spacing Bug with \pdfliteral direct Initial Comment: "\pdfliteral direct" screws up spacing. Hans found it. Therefore one has to use the non-direct variant e. g. for changing color in text, which results in tedious transforms. The trivial patch seems to solve this. Now it's possible to define color "direct". See the test.pdf file. Actually i don't understand at all what the patch does, but it seemed to be the only place where the literal interferes with position calculations. It seems that the patch does not mangle the horizontal positioning calculation; see the placement of the \vrule after the ET, which is independent from whether \pdfliteral direct is used or not. Rough patch. Tests welcome. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=389&group_id=106

1 0

[ pdftex-Bugs-384 ] Cannot mark text on pdfTeX-generated PDF files with highlighter tool (yellow fluorescent marker) of Acrobat Pro 7.02 on Mac OS X
by noreply＠sarovar.org 12 Jul '05

12 Jul '05

Bugs item #384, was opened at 2005-07-10 11:18 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=384&group_id=106 Category: None Group: v1.10b >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Mike Sturt (pdfx) Assigned to: Hans Hagen (hagen) Summary: Cannot mark text on pdfTeX-generated PDF files with highlighter tool (yellow fluorescent marker) of Acrobat Pro 7.02 on Mac OS X Initial Comment: pdfTeX is not fully compatible with Adobe Acrobat Pro 7.02. Here are the facts. More at <http://www.adobeforums.com>, that goes to <http://www.adobe.com/support/forums/main.html> and then click "Adobe Acrobat Mac" and then the message "Cannot mark text with highlighter tool (yellow fluorescent marker) of Acrobat Pro 7.02 on Mac OS X". In short: pdfText generates PDF files that have the following bug: I can select and mark text on such PDF files with the highlighter tool (sort of yellow fluorescent marker) the very first time that I open a document. Yet, the next time in a row, it is not possible (instead the text below is selected and yellow-marked in an erratic way. Tested with Acrobat Pro 7.02 on Mac OS X 10.3.9. Try with this file: http://www.boe.es/boe/dias/2005-07-01/pdfs/A23458-23458.pdf The culprit is pdfTeX, as explained in the Adobe Forum indicted above: ----- I examined the file internally, and it claims to have been made by pdfTeX version 3.14159-1.10b. It also messes up other information. Creator (which should be the name of the software designing the page) is a filename. Author, which should have been BOE, is blank. To anyone who knows PDF, this sort of thing will ring alarm bells! ----- Note: the workaround is to open the file with Adobe Acrobat Pro and then: Advanced>Accessibilty>Add Tags to document. If possible, please this annoying bug so that PDF files created withpdfTeX do not have such problem. Thanks. ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2005-07-10 23:04 Message: Logged In: YES user_id=927 i did s quick test - it concerns pdf pages inserted into tex - the inserted text has a funny baseline distance (watch how some lines touch - text selection goes ok, so the problem is not in pdftex - my guess is that the comment tool is unable to determine the proper line distance -- it skips lines -- also keep in mind that the comment feature is an annotation and needs to create some rectangle like specs which then end up on the annotation layer Hans - my impression is that ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-10 16:17 Message: Logged In: YES user_id=421 Attaching http://www.boe.es/boe/dias/2005-07-01/pdfs/A23458-23458.pdf ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-10 16:14 Message: Logged In: YES user_id=421 pdfTeX allows the document to override any keys it will insert into the document info (like Creator) and does not automatically set the Author entry, so the culprit here is BOE, not the software. On the highlighting problem I have no clue, as I also have no Acrobat Pro (Adobe does not provide a version for Linux). Hans? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=384&group_id=106

1 0

[ pdftex-Bugs-377 ] unqoute image filenames not only on windows
by noreply＠sarovar.org 12 Jul '05

12 Jul '05

Bugs item #377, was opened at 2005-07-02 21:43 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=377&group_id=106 Category: Image inclusion >Group: v1.21a >Status: Closed >Resolution: Wont Fix >Priority: 3 Submitted By: Georg Baum (baum) Assigned to: Martin Schröder (oneiros) Summary: unqoute image filenames not only on windows Initial Comment: The file pdftex-1.30.0-rc1/src/texk/web2c/pdftexdir/writeimg.c contains in the function readfile() a code block to unqoute file names which is inside #ifdef WIN32 ... #endif. This code should be enabled on all platforms (or at least on linux), since quoted filenames (which are necessary if the name contains spaces) do not only work well on linux. Thanks, Georg ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2005-07-05 10:57 Message: Logged In: YES user_id=1276 Hello, > I manually copied and cited your message because I could > not find out how to do that correctly with the tracker > system :-( Also the tiny typein area and the order of postings is very annoying. Perhaps we should better continue the discussion on the ntg-pdftex mailing list. >> Now you want the limitation of windows that quotes >> cannot be used apply on the other systems? > > I want to trade in the use of quotes for the use of > spaces. > Since you can only have one (not really, see below) it is > from a user's point of view better to support spaces on > all > platforms and not spaces on windows and quotes on other > platforms. >From a user's point it is better to support all characters instead of randomly choosen ones. The quoting method makes things worse: * There is no method to detect, whether quoting is supported: \includegraphics{"abc def.png"} The graphics package does not know, whether the TeX compiler will look for {abc def.png}, {"abc def.png"}, or {"abc}. Now you cannot use *both* quotes *and* spaces. * A very long time, spaces are considered "fancy" in file names, it is asking for trouble, because they are not supported on DOS file systems. But nowadays, spaces become "normal" despite the trouble (also on windows systems). The difference in our problem descriptions seems to be that you want to have *spaces* as usable characters in filenames, my conclusion is that we must allow *any* character as usable. Otherwise we will have bug reports about quotes. * And if we have a solution with *all* characters, there will be no problems with different encodings including ucs-2 or ucs-4. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Georg Baum (baum) Date: 2005-07-04 18:55 Message: Logged In: YES user_id=2590 Hello, I manually copied and cited your message because I could not find out how to do that correctly with the tracker system :-( > I must disagree, "the same behaviour on all platforms" > can not mean to add the limitations of all platforms. No, that is not my intention. > Now you want the limitation of windows that quotes > cannot be used apply on the other systems? I want to trade in the use of quotes for the use of spaces. Since you can only have one (not really, see below) it is from a user's point of view better to support spaces on all platforms and not spaces on windows and quotes on other platforms. > There are operating systems that deal with 8+3 file > names only. Do you want to forbid long file names, > for example? Of course not. > Thus we are loosing both quotes and spaces. Spaces still > cannot be used in general. Other TeX engines > does not know about quoting. There is no secure way > to know, whether quoting is working. Thus code that > is intended for different systems must avoid spaces. And quotes (in the filename itself, not for quoting), so this is not really an argument to support them. Concerning other implementations: \includegraphics{foo.png} does not work with plain latex, but with pdflatex. The same would apply to spaces in filenames, so I see no big problem there. > And the current quoting scheme does not solve the > problem at all, it moves the problem from spaces to > quotes, spaces can still not be used and quotes are > now made unavailable. Also the quoting scheme does > not allow quoting of the quotes themselves. It does (although I am not sure whether that is intended): Only the first quote is stripped from two consecutive quotes, e.g. the string '"a""bc"' is transformed into 'a"bc'. > A solution would allow *all* characters. > The solution should be able to deal with utf-8 or > even ucs-2/4 encoded file names. Agreed. If you think that the quoting is so bad then why not remove it altogether and tell users to use \pdfximage? My problem with the current implementation is the inconsistency: If filenames with spaces work on windows if quoted, I expect that they work on linux, too, since the OS supports them. Of course I can't expect the same from filenames with quotes: They are not supported by windows, so they can't be supported by pdftex on windows. I hope I have made my point clear. I can live with it if you still don't agree, so I'll stop arguing now. Georg ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2005-07-04 16:07 Message: Logged In: YES user_id=1276 Hello, I must disagree, "the same behaviour on all platforms" can not mean to add the limitations of all platforms. Now you want the limitation of windows that quotes cannot be used apply on the other systems? There are operating systems that deal with 8+3 file names only. Do you want to forbid long file names, for example? Thus we are loosing both quotes and spaces. Spaces still cannot be used in general. Other TeX engines does not know about quoting. There is no secure way to know, whether quoting is working. Thus code that is intended for different systems must avoid spaces. And the current quoting scheme does not solve the problem at all, it moves the problem from spaces to quotes, spaces can still not be used and quotes are now made unavailable. Also the quoting scheme does not allow quoting of the quotes themselves. A solution would allow *all* characters. The solution should be able to deal with utf-8 or even ucs-2/4 encoded file names. That is already given by the syntax of \pdfximage. Thus new primitives \pdfinput, \pdfopenin, \pdfopenout with <general text> would allow any file name and a macro code can test, whether this feature is available by testing the command names. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Georg Baum (baum) Date: 2005-07-04 13:46 Message: Logged In: YES user_id=2590 I agree that the quote stripping is a hack and should eventually be replaced by something better. I do think however that the behaviour on all platforms should be the same if it is at all possible. Right now, filenames with quotes work on linux and not on windows, and quoted filenames with spaces work on windows but not on linux. Thanks for the hint to pdfximage, I did not know about that (coming from standard LaTeX and always using \includegraphics} Georg ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2005-07-04 13:13 Message: Logged In: YES user_id=1276 Hello, it is a very bad idea, quotes are perfectly legal in linux and other operating systems. Also image inclusion is done by \pdfximage that uses <general text>, by <general text>, text surrounded by curly braces (catcode 1 and 2) *all* possible file names can be given including quotes and spaces. We need rather new primitives for \input, \openin, and \openout to provide the file names as <general text>. The all file names can be given without the need of quoting at all. See also the discussion about \pdfinput in the ntg-pdftex mailing list. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=377&group_id=106

1 0

[ pdftex-Feature Requests-385 ] \ptexnoligatures should leave kerning intact
by noreply＠sarovar.org 12 Jul '05

12 Jul '05

Feature Requests item #385, was opened at 2005-07-10 17:38 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=385&group_id=106 >Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robert (schlcht) >Assigned to: Nobody (None) >Summary: \ptexnoligatures should leave kerning intact Initial Comment: % The new \ptexnoligatures primitive will break the % horizontal positioning of \mathaccents if the base % character is slanted. % There is no problem with \accent, nor with \mathaccent % on upright characters: $\dot{A} \dot{\rm{A}} \dot{\Delta} \dot{\mit\Delta}$ {\tenit \accent'137 A} \ptexnoligatures\tenit % OK \ptexnoligatures\textfont0 % = cmr10, \rm % OK \ptexnoligatures\textfont1 % = cmmi10, \mit % breaks shift $\dot{A} \dot{\rm{A}} \dot{\Delta} \dot{\mit\Delta}$ {\tenit \accent'137 A} \bye, Robert ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2005-07-12 22:23 Message: Logged In: YES user_id=421 Changing this into a feature request. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-07-10 18:50 Message: Logged In: YES user_id=1608 This is because it (\ptexnoligatures) also disables the kerning information for the font. You'll have to accept that as a "known limitation" for now. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=385&group_id=106

1 0