July 2005 - ntg-pdftex - NTG Mailing Lists

[ 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