- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-498 ] pdftex leaves included files opened thus overflowing the ulimit
by noreply＠sarovar.org 27 Mar '06

27 Mar '06

Bugs item #498, was opened at 2006-03-27 01:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Closed Resolution: Works For Me Priority: 3 Submitted By: Vladimir Volovich (vvv) Assigned to: Martin Schröder (oneiros) Summary: pdftex leaves included files opened thus overflowing the ulimit Initial Comment: [re-sending through sarovar bug reporting form] i'm reporting a bug discovered by Tigran Aivazian: He got this message: pdflatex: ./1016.pdf: Too many open files by running pdflatex on this simple source: \documentclass[pdftex,a5paper]{book} \usepackage[papersize={8.5in,11in}]{geometry} \usepackage{pdfpages} \begin{document} \newcount\i \i=2 \loop \ifnum\i<1725 \includepdf[pages={-}]{\number\i.pdf}% \advance\i by1 \repeat \end{document} It appears that this is due to the "ulimit" on the number of simultaneously opened files which was 1024 by default. Increasing "ulimit" allowed to process the file. But it looks like a bug in pdftex: it seems that it keeps all the files which were \includepdf'ed opened, thus causing this limit to be reached. Instead, it seems, it should close the included files. WDYT? ---------------------------------------------------------------------- >Comment By: Vladimir Volovich (vvv) Date: 2006-03-27 11:39 Message: Logged In: YES user_id=2086 please clarify why non-\immediate \pdfximage is still allowed to leave the included files opened. (i.e. why the current behavior is considered normal, when the files are left opened and the ulimit eventually overflows). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-27 04:58 Message: Logged In: YES user_id=421 The "problem" here is that \pdfximage normally is not immediate. If you make it immediate by e.g. inserting \let\mypdfximage\pdfximage \def\pdfximage{\immediate\mypdfximage} everything works fine. So maybe pdfpages should work use an \immediate. We still need to fix the problem with the remaining broken file, but that is another bug. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-27 02:43 Message: Logged In: YES user_id=421 I at least found why the resulting file is not deleted (i.e. where pdfTeX actually crashes): The callstack is thus: - pdftex.web:scan_image - writeimg.c:readimage - writeimg.c:checktypebyheader - kpathsea/xfopen.c:xfopen, which calls FATAL_PERROR So we should register our error handler through atexit (3) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106

1 0

[ pdftex-Feature Requests-87 ] In case of fatal errors, delete the output file
by noreply＠sarovar.org 27 Mar '06

27 Mar '06

Feature Requests item #87, was opened at 2004-07-02 11:13 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106 Category: None Group: v1.21 Status: Open Resolution: None Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: In case of fatal errors, delete the output file Initial Comment: When pdfTeX currently encounters a fatal error, it closes it's output file, which leads to incomplete/corrupt files. pdfTeX should produce only valid files, and in case of fatal errors the output should be deleted. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-03-27 03:00 Message: Logged In: YES user_id=421 Currently we only handle exits through pdf_fail. But we also need to trap other exits; this must be done through atexit(3). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-12-19 00:38 Message: Logged In: YES user_id=421 The attached patch unlinks the current file, if a fatal error happens. Currently this is done without any checks, and may be a security problem. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 14:35 Message: Logged In: YES user_id=1608 When you truncate a file, the result is an empty file. From a user's viewpoint, that is not the same thing as a corrupt PDF. The distinction is small, but the advantage of an empty file is that it is not likely to be confused for a correct PDF. If it is possible, then deleting the PDF file is definately better, but file deletion doesn't always work. Truncation almost always does work, and it's only two syscalls extra, so why not? ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2004-07-02 14:21 Message: Logged In: YES user_id=421 Simply truncating a pdf still makes it invalid (because the file structure is incomplete). Producing a valid truncated output file in case of fatal errors will be tricky and not always possible. Deleting the corrupt output is much easier. ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2004-07-02 13:50 Message: Logged In: YES user_id=1608 If deleting the file doesnt work, truncation is probably still better than nothing. (?) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=87&group_id=106

1 0

[ pdftex-Bugs-498 ] pdftex leaves included files opened thus overflowing the ulimit
by noreply＠sarovar.org 27 Mar '06

27 Mar '06

Bugs item #498, was opened at 2006-03-26 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Category: PDF inclusion Group: v1.30.0 >Status: Closed >Resolution: Works For Me >Priority: 3 Submitted By: Vladimir Volovich (vvv) Assigned to: Martin Schröder (oneiros) Summary: pdftex leaves included files opened thus overflowing the ulimit Initial Comment: [re-sending through sarovar bug reporting form] i'm reporting a bug discovered by Tigran Aivazian: He got this message: pdflatex: ./1016.pdf: Too many open files by running pdflatex on this simple source: \documentclass[pdftex,a5paper]{book} \usepackage[papersize={8.5in,11in}]{geometry} \usepackage{pdfpages} \begin{document} \newcount\i \i=2 \loop \ifnum\i<1725 \includepdf[pages={-}]{\number\i.pdf}% \advance\i by1 \repeat \end{document} It appears that this is due to the "ulimit" on the number of simultaneously opened files which was 1024 by default. Increasing "ulimit" allowed to process the file. But it looks like a bug in pdftex: it seems that it keeps all the files which were \includepdf'ed opened, thus causing this limit to be reached. Instead, it seems, it should close the included files. WDYT? ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-03-27 02:58 Message: Logged In: YES user_id=421 The "problem" here is that \pdfximage normally is not immediate. If you make it immediate by e.g. inserting \let\mypdfximage\pdfximage \def\pdfximage{\immediate\mypdfximage} everything works fine. So maybe pdfpages should work use an \immediate. We still need to fix the problem with the remaining broken file, but that is another bug. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2006-03-27 00:43 Message: Logged In: YES user_id=421 I at least found why the resulting file is not deleted (i.e. where pdfTeX actually crashes): The callstack is thus: - pdftex.web:scan_image - writeimg.c:readimage - writeimg.c:checktypebyheader - kpathsea/xfopen.c:xfopen, which calls FATAL_PERROR So we should register our error handler through atexit (3) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106

1 0

[ pdftex-Bugs-498 ] pdftex leaves included files opened thus overflowing the ulimit
by noreply＠sarovar.org 26 Mar '06

26 Mar '06

Bugs item #498, was opened at 2006-03-26 23:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Category: PDF inclusion >Group: v1.30.0 Status: Open >Resolution: Accepted >Priority: 7 Submitted By: Vladimir Volovich (vvv) Assigned to: Martin Schröder (oneiros) Summary: pdftex leaves included files opened thus overflowing the ulimit Initial Comment: [re-sending through sarovar bug reporting form] i'm reporting a bug discovered by Tigran Aivazian: He got this message: pdflatex: ./1016.pdf: Too many open files by running pdflatex on this simple source: \documentclass[pdftex,a5paper]{book} \usepackage[papersize={8.5in,11in}]{geometry} \usepackage{pdfpages} \begin{document} \newcount\i \i=2 \loop \ifnum\i<1725 \includepdf[pages={-}]{\number\i.pdf}% \advance\i by1 \repeat \end{document} It appears that this is due to the "ulimit" on the number of simultaneously opened files which was 1024 by default. Increasing "ulimit" allowed to process the file. But it looks like a bug in pdftex: it seems that it keeps all the files which were \includepdf'ed opened, thus causing this limit to be reached. Instead, it seems, it should close the included files. WDYT? ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2006-03-27 00:43 Message: Logged In: YES user_id=421 I at least found why the resulting file is not deleted (i.e. where pdfTeX actually crashes): The callstack is thus: - pdftex.web:scan_image - writeimg.c:readimage - writeimg.c:checktypebyheader - kpathsea/xfopen.c:xfopen, which calls FATAL_PERROR So we should register our error handler through atexit (3) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106

1 0

[ pdftex-Bugs-498 ] pdftex leaves included files opened thus overflowing the ulimit
by noreply＠sarovar.org 26 Mar '06

26 Mar '06

Bugs item #498, was opened at 2006-03-27 01:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106 Category: PDF inclusion Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vladimir Volovich (vvv) Assigned to: Martin Schröder (oneiros) Summary: pdftex leaves included files opened thus overflowing the ulimit Initial Comment: [re-sending through sarovar bug reporting form] i'm reporting a bug discovered by Tigran Aivazian: He got this message: pdflatex: ./1016.pdf: Too many open files by running pdflatex on this simple source: \documentclass[pdftex,a5paper]{book} \usepackage[papersize={8.5in,11in}]{geometry} \usepackage{pdfpages} \begin{document} \newcount\i \i=2 \loop \ifnum\i<1725 \includepdf[pages={-}]{\number\i.pdf}% \advance\i by1 \repeat \end{document} It appears that this is due to the "ulimit" on the number of simultaneously opened files which was 1024 by default. Increasing "ulimit" allowed to process the file. But it looks like a bug in pdftex: it seems that it keeps all the files which were \includepdf'ed opened, thus causing this limit to be reached. Instead, it seems, it should close the included files. WDYT? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=498&group_id=106

1 0

Changing the pdfTeX banner for Debian-specific changes
by Frank Küster 24 Mar '06

24 Mar '06

Hi, this might already be resolved - we're still dealing with pdfTeX 1.21a in teTeX -, but also not, and therefore interest you. Julian Gilbey <jdg(a)polya.uklinux.net> wrote: >> >> as requested by Martin Schr?der, the pdfTeX maintainer, I'd like to add >> >> something about libpoppler to the "pdeftex --version" output or the >> >> general banner, but I don't manage. According to him, it should be >> >> sufficient to change texk/web2c/pdfetexdir/pdfetexextra.in, but that >> >> doesn't have any effect here - probably we have such an ancient version >> >> (1.20 instead of 1.40 in which he is thinking...). >> > >> > Just modifying the #define BANNER=... line in that file does it for >> > me. >> >> Strange - I tried and got funny results, e.g. after changing >> >> #define BANNER "This is pdfeTeX, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" >> >> to >> >> #define BANNER "This is not pdfeTeX, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" >> >> it printed "not pdfeTeX..." instead of "This is pdfeTeX..." > > With the normal version, compare: > > burnside:~ $ pdfetex --version > pdfeTeX 3.141592-1.21a-2.2 (Web2C 7.5.4) > kpathsea version 3.5.4 > Copyright (C) 1997-2004 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). > Kpathsea is copyright (C) 1997-2004 Free Software Foundation, Inc. > [...] > > with: > > burnside:~ $ pdfetex > This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) > ** > > It turns out that when producing the version string for --version in > lib/printversion.c, function printversionandexit, the leading prefix > "This is " is stripped off from the banner name. Furthermore, the > banner string is parsed like this: > > "This is pdfeTeX, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" > ^^^^^^^^------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > stripped name progversion > > where "This is " is stripped, the prog name goes up to the first > comma, and the progversion is everything after the final space; then > the first line of the --version output is: > > name progversion (Web2C-version) Therefore it is indeed hard to add information about local changes, which naturally would be at the end (after an additional space). > So if all is wanted is to tweak the banner line, there are two ways to > do it: > > (1) Hackish: define BANNER to be something like: > "This is pdfeTeX with Debian tweaks, Version 3.141592-PDFTEX-VERSION-ETEX-VERSION" I'll go that way, but I'd appreciate if in future versions it would be possible to just add a "local_changes_remark" at an appropriate place (either the end of the line, or an additional line. > (2) Actually modify the printversionandexit code in lib/printversion.c > to output something like: > > string debianversion = "(Debian version blah)"; > > len = prog_name_end - banner - sizeof ("This is") + sizeof(debianversion); > prog_name = (string)xmalloc (len + 1); > strncpy (prog_name, banner + sizeof ("This is"), len); > prog_name[len] = 0; > > /* The Web2c version string starts with a space. */ > printf ("%s %s%s %s\n", prog_name, prog_version, versionstring, debianversion); > > and a similar change in one of the change files. > > But the latter seems like hard work :/ Should I open a feature request? Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)

1 0

Creating identical PDF files with different pdfTeX runs
by Frank Küster 20 Mar '06

20 Mar '06

Hi, we (i.e. a couple of Debian developers, taking up old ideas of each individual and the tests in http://tug.org/svn/texlive/trunk/Master/support/tests/) are trying to implement some automated testing of pdf and dvi creation by pdftex. Possible applications are regression tests for the binary, for distributions (changed font setup etc.), or for package authors ("does the new version still cooperate with hyperref?"). For this, it would be great if it were possible to create identical pdf files in subsequent runs of pdfTeX. With \pdfinfo{/CreationDate (1980-09-09)} \year=1980 \month=9 \day=9 \time=10 \pdfcompresslevel0 I get pdf files that can be compared, but only after some grepping: egrep -a -v '/BaseFont|/FontName|/UniqueID|/ID|/CreationDate' $< > $@ With dvipdfmx (and perhaps with newer pdfTeX versions than the one in teTeX) /CMap or something like this needs to be excluded, too. Is it possible to achieve identical pdf files directly, by adding the proper commands, or would it be possible to add this feature? TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)

8 24

/cwm
by Reinhard Kotucha 13 Mar '06

13 Mar '06

Hi, /cwm (compwordmark) in AGL or #200C in Unicode, see: http://www.unicode.org/charts (ZERO WIDTH NON JOINER) is a glyph with zero width which is intended to mark word boundaries. In German, the word "Auflage" should not contain an "fl"-ligature because it is composed from two words. There is a macro which allows for breaking such ligatures in german.sty and babel[german]. The glyph /cwm has never been used by TeX but Walter considers to make use of it in the future. The advantage would be that the behaviour of the TeX macro which breaks ligatures at word boundaries will depend on the font, while it is unaware of the font currently in use now. If I understood Walter correctly, he wants to add kerning at such word boundaries in a way that the amount of kerning depends on the current font. Currently the same amount of kerning is applied to all fonts. However, I'm sure that the glyph /cwm is missing in many fonts. On the other hand, if we need kerning, we do not need a special glyph from a font, create a virtual font with modified metrics, and so on. When we have OTF support some day, I assume that we need some new primitives anyway which support additional metrics derived from OTF files which are not supported by \fontdimen. As far as I can see, it's reasonable to add a new primitive so that you can write \font\myfont=xyz \myfont \compwordkern\font = .2em The TeX macro which breaks ligatures then can insert \compwordkern for the current font. This way we can have different kernings for different fonts and we are completey independ of the fonts we use. And, of course, I assume that microtype.sty will hide all the low-level stuff... 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. ----------------------------------------------------------------------------

2 3

DANTE 2006
by Reinhard Kotucha 13 Mar '06

13 Mar '06

Hi, for all of you who had not the opportunity to come to Berlin, here is a short summary of pdfTeX related talks. Till Tantau, the author of beamer, held a talk about TikZ (a frontend to pgf, the portable graphics format) which is a very powerful macro package to prepare inline graphics in latex/plain/context documents. Currently pgf does all calculations in tex, which is quite limited. He is looking forward to make use of LuaTeX in the future. He expects that trigonometric functions will be about hundred times faster then, and TikZ will be more powerful as it is today. Jonathan Kew gave an impressive demonstration of XeTeX. Though it runs on Mac OS/X systems at the moment only, he plans to port it to Linux and maybe Windows so that it can be part of TeXLive-2006. He said that both, XeTeX and pdfTeX, are moving targets at the moment, but he is thinking about merging them in the future. Yannis Haralambous held a talk with the title "Implementing OpenType and textemes into Omega". He already talked about it in Pont-a-Mousson, see: http://www.dante.de/dante/events/eurotex/papers/MOT02.pdf The good news is that he intends to present the pre-processor as a stand-alone program providing XML output at the EuroTeX 2006. Martin held a talk with the title "pdfTeX - gestern, heute, morgen" ("pdfTeX - yesterday, today, tomorrow") but I think there is no need to go into detail on this mailing list. Martin and Hartmut will hopefully tell you everything I forgot. 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. ----------------------------------------------------------------------------

2 1

Reminder: \pdfretval exists
by Martin Schröder 03 Mar '06

03 Mar '06

Hi, just a reminder: \pdfretval exists. Currently it's only used with \pdfobj useobjnum. I'm sure there are more uses. :-) Best Martin -- http://www.tm.oneiros.de

1 0

making links work in rotated text
by Vladimir Volovich 02 Mar '06

02 Mar '06

Hi! if i typeset e.g. a table in LaTeX's landscape environment, and there are some links in the table, they become not clickable because of rotation. it is a known problem, as far as i can tell (searching in google shows that; the reason seems to be that the clickable areas links remain where they were before the rotation, i.e. they are not affected by the rotation, unlike the text)... is there any hope that this problem is going to be solved in not too distant future? :) Best, v.

6 13

Re: [NTG-pdftex] [pdftex] pdftex, dvipdfmx, encguide
by Hartmut Henkel 28 Feb '06

28 Feb '06

On Tue, 28 Feb 2006, Hans Hagen wrote: > Werner LEMBERG wrote: > > > > I thought I'd pass on this recent note from Werner about pdftex > > > > generating a much larger file than dvipdfmx. [...] > > > > > > > thanks a lot. Very interesting! This was done with 1.21a, but even > > > the new 1.40.0-beta is not better. > > > > This is the very reason why pdftex is a bad choice for documents > > written in a CJK script. > > > indeed, although i remember that thanh looked into it (or was going to > look into it) > > it should be put high on the agenda it is there, now :-) The /Encoding in the embedded Type1 font file should be independent from an external encoding. Currently the external encoding is duplicated also in the font, unnecessarily, as this info is ignored anyway, due to the full external /Encoding. So we might have similar fonts in the PDF that differ only by their unused encodings. I believe we should keep the original /Encoding inside the font intact (unused anyway, only for information), using the value pairs coming with the font file. We can reduce the size of the /Encoding vector in the font so that only the entries of actually used glyphs are there. E. g. if an external /Encoding says 13 --> /foo and the internal original encoding says 55 --> /foo then if 13 --> /foo is typeset by pdftex, we need to lookup /foo in some hash or tree for the font file so we get the original 55 which goes into the subsetted font file stream. I'll try this. Then there is some magic needed to trigger glyph activation in one PFB file only... Regards, Hartmut

1 0

[ pdftex-Patches-438 ] \pdfsavepos in DVI mode
by noreply＠sarovar.org 28 Feb '06

28 Feb '06

Patches item #438, was opened at 2005-10-16 21:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106 Category: Positioning Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Hartmut Henkel (hhenkel) Summary: \pdfsavepos in DVI mode Initial Comment: \pdfsavepos in DVI mode Hello, using \pdfsavepos in a package of mine (tabularht) I was wondering, why \pdfsavepos is not allowed to work in DVI mode. \pdfsavepos in PDF mode is based on cur_h and cur_v, both coming from the DVI frontend. The only difference I found is that the PDF format and pdfTeX's PDF mode know about page dimensions. Thus the directions of the axes are the same for the PDF format and the values of \pdfsavepos (\pdflastxpos, \pdflastypos). Origin: lower left corner horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp The DVI case doesn't know about page dimensions, thus I suggest using cur_h=0 and cur_v=0 as origin. It is the left upper corner of the box that is being shipped out. Origin: left upper corner of the box horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp Thus the absolute values differ in both modes and I don't see that this can be avoided. However, if the application uses a reference point then the relative values are exactly the same. The attachted patch enables and implements \pdfsavepos for the DVI mode. It also contains the patch for bug 437 (Two \immediate cancel themselves). Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-02-28 00:24 Message: Logged In: YES user_id=927 positioning has always been available in dvi mode as well by means of specials and postprocessing the dvi file (first by a script by taco, later by the dvipos program that comes with dvipdfmx); btw, when you mean 'the current drivers' you refer to latex, and you cannot assume that those are used outside latex, so that is no real reference -) in a similar fashion the dvipos functionality is no real reference either since it is mainly meant for appending info to the context second-pass-info file; anyhow, since pdftex is now the standard engine, there is no need to support the dvipos specials (apart from backward compatibility in context) because we had a "pos:papersize w h" special, dvipos could provide the same reference frame as when using the pdftex primitives; therefore, using the pdfpagewidth and pdfpageheight specification as in the suggested latest patch) is the best way to go (at least for context) (Since we now have pdfpagewidth/height in dvi mode, we get less and less \pdfprimitives that complain in dvi mode) Hans ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2005-10-17 11:39 Message: Logged In: YES user_id=1276 Hello, I have now extended the patch: \pdfpagewidth/height are now used for the page dimensions. Also the funny DVI origin offset of 1in is taken into account. Thus the values in DVI and PDF mode are the same. The exception is \pdf{h,v}origin. If the value is not 1in, then the values differ in DVI and PDF mode. However, also the DVI and PDF output will differ in this case. Thus the different values are then ok, I think. If someone wants to have the same values, he just sets \pdfpage{width,height} and let \pdf{h,v}origin untouched. Hartmut Henkel wrote: > to give page dimension info for pdftex also in > DVI mode, one could implement the standard > \special{papersize=x,y} also in pdftex (parallel > to \pdfpagewidth/height), so that it would be > scanned, and also go into the DVI file. Would > this help? I think, not really: * Scanning of \specials are done in PDF mode already, but here it is not really necessary, the current drivers know about \pdfpage{width,height}. * In DVI mode, the scanning of \special's contents must then be added to set \pdfpage{width,height}. But who needs this actually? * Relative positioning with \pdfsavepos works with or without the correct page size information. * Absolute positioning is more difficult in use (If you are somewhere in a box, how do you want to apply absolute positions?) * If someone insist on absolute positioning, he will probably not rely on an accidentally issued \special{papersize=...}. He will probably make sure, that the papersize information is set and then he can also set \pdfpage{width,height}. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: The name of the patch file is now "v2-pdftex.ch.diff". And I have removed the patch of fixed bug 437. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-16 22:16 Message: Logged In: YES user_id=929 to give page dimension info for pdftex also in DVI mode, one could implement the standard \special{papersize=x,y} also in pdftex (parallel to \pdfpagewidth/height), so that it would be scanned, and also go into the DVI file. Would this help? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106

1 0

[ pdftex-Patches-466 ] \primitive and \ifprimitive
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #466, was opened at 2006-01-07 17:22 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106 Category: Primitives >Group: v1.30.0 Status: Open Resolution: Accepted Priority: 4 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \primitive and \ifprimitive Initial Comment: This patch implements two new primitives: \primitive \par This will run the 'primitive' command \par, even if it has been re- or undefined in the meantime. \primitive is not expandable, because it may be asked to execute unexpandable primitives as well as expandable ones. If you supply a nonexistant primitive, it will be ignored (no error is raised). The second primitive is a new type of \if: \ifprimitive \par ... \else .. \fi returns true if the current meaning of \par is the 'primitive' command \par. The patch is against alpha-20051226, i hope that is not too old (?). I expect to do at least one minor update during the beta cycle, after the pdftex code is flattened. It was quite a struggle to make this change file work ok, and as a result, there are a few ugly web hacks. ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-14 08:17 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-02-13 18:56 Message: Logged In: YES user_id=1608 We need to think about this. I see your point, but making \primitive expandable forces the introduction of un-redefinable tokens, and that has its own problematic side-effects (like slowing down each and every definition). I welcome third opinions on whether the benefits outweigh that downside. At one point I tried making the expandability depend on the referred primitive, but that gave me headaches at the implementation stage (a pity, because that would have been nice). Yet another solution is to have an expandable command as well as an unexpandable command (two primitives instead of just the single \primitive). On the side note: I will happily write an implementation ... but only if someone comes up with a specification that works under all conditions instead of only under specific programming styles :-) ---------------------------------------------------------------------- Comment By: Bernd Raichle (bernd) Date: 2006-02-13 17:40 Message: Logged In: YES user_id=3344 IMHO it would be better to rephrase the above to (and change the implementation accordingly :-(): <quote mode="changed"> \primitive is expandable, because it may asked to execute expandable primitives as well as unexpandable ones. \primitive<cs> will expand to one token, the original TeX primitive. This token will then be processed further as usual. </quote> If \primitive is left unexpandable, a lot of programming techniques seems to be unavailable, e.g., all redefined expandable primitives in expandable-only context. Or any assignment to the get the original primitive, like \edef\orignumber{\expandafter\noexpand\primitive\number} \expandafter\let\expandafter\orignumber\primitive\number Sidenote: The new \primitive seems to implement a subset of a full-blown namespace mechanism. If (pdf)TeX would have namespaces, one simply has to access the appropriate token within the "primitive" namespace (e.g. \primitive::number to access the original \number primitive, assuming the notation \<namespace>::<csname>). How about choosing an appropriate namespace mechanism for (pdf)TeX and implementing it instead? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=466&group_id=106

1 0

[ pdftex-Patches-438 ] \pdfsavepos in DVI mode
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #438, was opened at 2005-10-16 23:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106 Category: Positioning >Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Hartmut Henkel (hhenkel) Summary: \pdfsavepos in DVI mode Initial Comment: \pdfsavepos in DVI mode Hello, using \pdfsavepos in a package of mine (tabularht) I was wondering, why \pdfsavepos is not allowed to work in DVI mode. \pdfsavepos in PDF mode is based on cur_h and cur_v, both coming from the DVI frontend. The only difference I found is that the PDF format and pdfTeX's PDF mode know about page dimensions. Thus the directions of the axes are the same for the PDF format and the values of \pdfsavepos (\pdflastxpos, \pdflastypos). Origin: lower left corner horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp The DVI case doesn't know about page dimensions, thus I suggest using cur_h=0 and cur_v=0 as origin. It is the left upper corner of the box that is being shipped out. Origin: left upper corner of the box horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp Thus the absolute values differ in both modes and I don't see that this can be avoided. However, if the application uses a reference point then the relative values are exactly the same. The attachted patch enables and implements \pdfsavepos for the DVI mode. It also contains the patch for bug 437 (Two \immediate cancel themselves). Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2005-10-17 13:39 Message: Logged In: YES user_id=1276 Hello, I have now extended the patch: \pdfpagewidth/height are now used for the page dimensions. Also the funny DVI origin offset of 1in is taken into account. Thus the values in DVI and PDF mode are the same. The exception is \pdf{h,v}origin. If the value is not 1in, then the values differ in DVI and PDF mode. However, also the DVI and PDF output will differ in this case. Thus the different values are then ok, I think. If someone wants to have the same values, he just sets \pdfpage{width,height} and let \pdf{h,v}origin untouched. Hartmut Henkel wrote: > to give page dimension info for pdftex also in > DVI mode, one could implement the standard > \special{papersize=x,y} also in pdftex (parallel > to \pdfpagewidth/height), so that it would be > scanned, and also go into the DVI file. Would > this help? I think, not really: * Scanning of \specials are done in PDF mode already, but here it is not really necessary, the current drivers know about \pdfpage{width,height}. * In DVI mode, the scanning of \special's contents must then be added to set \pdfpage{width,height}. But who needs this actually? * Relative positioning with \pdfsavepos works with or without the correct page size information. * Absolute positioning is more difficult in use (If you are somewhere in a box, how do you want to apply absolute positions?) * If someone insist on absolute positioning, he will probably not rely on an accidentally issued \special{papersize=...}. He will probably make sure, that the papersize information is set and then he can also set \pdfpage{width,height}. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: The name of the patch file is now "v2-pdftex.ch.diff". And I have removed the patch of fixed bug 437. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-17 00:16 Message: Logged In: YES user_id=929 to give page dimension info for pdftex also in DVI mode, one could implement the standard \special{papersize=x,y} also in pdftex (parallel to \pdfpagewidth/height), so that it would be scanned, and also go into the DVI file. Would this help? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106

1 0

[ pdftex-Patches-434 ] Remove queued map item handling
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #434, was opened at 2005-10-13 01:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106 Category: Fonts >Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Taco Hoekwater (taco) Summary: Remove queued map item handling Initial Comment: Remove queued map item handling from mapfile.c ============================================== Formerly all items from \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} were queued up in a list until the next font was selected; then the whole list was processed, e. g. all queued mapfiles or maplines read in. When one gave \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-=, the pending list was cleared. The only practical use for this was to prevent reading in the default mapfile. But this can be done simpler, without queuing. With this patch all \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} requests are processed completely and immediately without queuing, which means that if e. g. a \pdfmapfile{+-=mapfile} primitive is scanned, the mapfile will be read in right away. This happens independently from selecting a font. When \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} is scanned, and there is a default mapfile, it is read first and then the mapfile. Reading of the default mapfile can be disabled by \pdfmapfile{} or \pdfmapline{} or \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-= as long as the default mapfile hasn't already been read in. Latest when the first font is requested, the default mapfile will be read, if this hasn't already been disabled by the mentioned primitives. Apart from possibly reading the default mapfile, there is no other action when a font is requested, since the \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} primitives have already acted right away when they were called. The effects of this patch are the following: * Initial mapfile reading still can be blocked in the usual way. * The difficult to describe queuing mechanism has gone, code gets simpler. * Mapfile reading happens directly by the primitives. * Therefore it's possible to use \pdfretval with the primitives, to check success of the mapfile/line reading (not yet implemented). * As the return value is connected to the \pdfmapfile or \pdfmapline call, one can easier implement other map setting primitives and give them return values. This was not possible before, as the queuing was inbetween. * For any standard use, the patch should be compatible to the former queuing method. The mapfile.c is a patched version of the mapfile.c from Thanh's subfont patch pdftex-20050924.patch.gz for pdftex-1.30.3. Hope it doesn't sound too messy :-) For discussion. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106

1 0

[ pdftex-Patches-432 ] Rules in a PDF qQ group
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #432, was opened at 2005-10-06 21:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106 Category: Positioning >Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hans Hagen (hagen) Summary: Rules in a PDF qQ group Initial Comment: Put rules with their positioning on the page inside a qQ group. Should make \pdfliteral page {...} behave consistently after text or rules or images, as then any positioning starts from the PDF origin; no delta-positioning anymore. It's already being tested in pdfluatex. Just to have it at sarovar... Testing welcome, particularily with text and graphics transforms by graphicx package, to spot backward incompatibilities, if any... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:07 Message: Logged In: YES user_id=929 Update pdf_set_origin_temp: Now has (h, v) parameters. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106

1 0

[ pdftex-Patches-427 ] Character positioning patch
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #427, was opened at 2005-09-11 12:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106 Category: Positioning >Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hans Hagen (hagen) Summary: Character positioning patch Initial Comment: Experimental patch increases resolution of /Widths array by 1 fractional digit, makes corrections of type ")-1(" and ")1(" in the TJ array happen much less often, particularily for CM fonts. Gives e. g. 1 % PDF file size shrink for pdfetex web sources compiled into PDF. Rough patch only, not for production. Testing welcome. Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:06 Message: Logged In: YES user_id=929 Patch extended: Now pdf_set_origin has (h, v) parameters, simplifies pdf_begin_text procedure. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 00:25 Message: Logged In: YES user_id=929 Removed pdf_first_space_corr variable, as it seems that it was defunct anyway: There was no pdf_end_string procedure call (only place where something is done with pdf_first_space_corr), where afterwards the pdf_h variable (then modified by pdf_first_space_corr) would actually be used. E. g. pdf_moveto uses pdf_last_h instead, and after pdf_end_text there is anyway a pdf_set_origin call. And pdf_begin_string gets simpler. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-03 01:16 Message: Logged In: YES user_id=929 patch updated: now the TJ array building in procedure pdf_begin_string is simplified/tidied up. Testing welcome! Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=427&group_id=106

1 0

[ pdftex-Patches-416 ] new primitive pdflastlink
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #416, was opened at 2005-08-19 09:42 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106 Category: Primitives >Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Ralf Utermann (ralfu) Assigned to: Hartmut Henkel (hhenkel) Summary: new primitive pdflastlink Initial Comment: This patch implements a new primitive \pdflastlink (analogous to \pdflastannot) which returns the object number of the last object created with \pdfstartlink. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=416&group_id=106

1 0

[ pdftex-Patches-415 ] various extensions and fixes
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #415, was opened at 2005-08-19 09:09 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106 Category: Primitives >Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: The Thanh Han (hanthethanh) Assigned to: Martin Schröder (oneiros) Summary: various extensions and fixes Initial Comment: This is a patch for various experimental extensions: - \pdfinsertht: return the height of an insert (requested by Hans); this has similar syntax to \pdftexrevision. - do not fail when \pdfobj is used with an invalid object number (requested by Hans) - snapping: support for grid typesetting -- see snap.txt for details - kern before space: allow changing interword glues in a flexible way and inserting a kern before certain characters -- see kern-before-interword-glue.txt for details The notes in snap.txt and kern-before-interword-glue.txt are from email correspondence with people interested in; hence these notes are somewhat informal, inaccurate or out-of-date. How to apply: ~~~~~~~~~~~~~ cd /path/to/pdftex-1.30.0-srcdir/src/texk patch -p1 < /path/to/pdftex-20050818.patch cd web2c make pdfetex ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-09-04 18:22 Message: Logged In: YES user_id=421 The patch for invalid object numbers is included in 1.30.1++ ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=415&group_id=106

1 0

[ pdftex-Patches-386 ] grow obj_tab and dest_names arrays dynamically
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #386, was opened at 2005-07-10 20:29 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=386&group_id=106 Category: Memory allocation >Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hartmut Henkel (hhenkel) Summary: grow obj_tab and dest_names arrays dynamically Initial Comment: experimental patch to grow the obj_tab and dest_names arrays dynamically; arrays initially have 1000 entries. This required also update of file avlstuff.c. Similar to patch-366, which did this already for the pdf_mem array. Then all (?) pdftex-specific memory configuration parameters, obj_tab_size, dest_names_size, and pdf_mem_size in texmf.cnf would be ignored. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=386&group_id=106

1 0

[ pdftex-Patches-469 ] \currentexpansionmode + \ifalignscanning - \ifinedef
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #469, was opened at 2006-01-12 02:39 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=469&group_id=106 Category: Primitives >Group: v1.40.0 Status: Open Resolution: Postponed Priority: 5 Submitted By: Morten Høgholm (morten) Assigned to: The Thanh Han (hanthethanh) Summary: \currentexpansionmode + \ifalignscanning - \ifinedef Initial Comment: Here's a patch made against pdftex-1.40.0-alpha-20060111. It removes the \ifinedef primitive for a different primitive, namely \currentexpansionmode. This read-only register is 0 when doing regular typesetting, 1 when inside \edef or \xdef and 2 in other cases of full expansion with scan_toks. It could possibly be extended to distinguish between \marks and \write etc. Comments more than welcome on this one! I have also added an \ifalignscanning test. It is true whenever TeX is looking for \noalign etc. so is most useful for a \stopalignscanning function defined as \def\stopalignscanning{\ifalignscanning\relax\fi} ---------------------------------------------------------------------- Comment By: Frank Mittelbach (mittelbach) Date: 2006-02-15 18:38 Message: Logged In: YES user_id=3421 concerning register versus individual \if... primitves: I agree that numeric values are less easy to read but if the numeric codes are well chosen then they have the advantage of not cluttering the code, eg if you have to test for a number of different cases then a set of nested \if's is also not really helpful. Suppose for example you have to do different actions depending on the type of expansion. Then the register allows you to do this in a since \ifcase or in some \ifnum ...> . But of course this only works is the order is adjusted to typical usages. And non-numerical ones could still be implemented efficently at the macro level, eg \def\ifinedef{\ifnum 1=\currentexpansionmode} as to \stopalignscanning: this is not identical to \protected as protection prevents expansion in all cases which is not necessarily what you need my 2 cents frank ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-17 23:22 Message: Logged In: YES user_id=927 concerning alignments: - how about adding \everyaligncell (in addition to \everycr) - how about the other iftests? - (and \nospan -) ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-16 21:23 Message: Logged In: YES user_id=3333 @None: An \ifalignscanning primitive can also help macros like LaTeX's \multicolumn and other code that relies on seeing \noalign or \omit to recover gracefully with a comprehensible error message. ---------------------------------------------------------------------- Comment By: Morten Høgholm (morten) Date: 2006-01-13 05:50 Message: Logged In: YES user_id=3333 Yes, just ideas here, which is why I asked for comments. We can discuss this on the list (once my subscription is accepted). ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2006-01-12 11:22 Message: Logged In: YES user_id=1608 Like Hans, I also prefer separate if primitives, mainly because I do not want to have to remember the meanings of the possible integer values (for that reason, I'm not too happy about \currentgrouptype either). Taco ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2006-01-12 10:14 Message: Logged In: NO i wonder why we need \ifalignscanning or \stopalignscanner at all when eTeX already has this feature - any \protected macro stops the scanning. ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2006-01-12 09:08 Message: Logged In: YES user_id=927 somehow i think that if's are a better idea than a register because in your case the register only registers one case at the same time (when i saw this patch the first time, i wondered why not a complete set was implemented) - ifincsname - ifinedef - ifinwrite - ifinspecial - ifinpdfliteral - ifinannotbody - ifinmessage (special case of write) - ifinalign - ifinmark probably some more (ok, normally all those conditions can comfortably be catched in a macro package but if we add them, we should be complete in addition to this there can be a register which keeps track of the innermost one (we can have ifcsname inside an edef inside an align concerning the \stopalignscanner i think it's better to have something primitive like \crcr, say \endalign because using if's can have its own problem (we should not worry to much about a name clash, since one can always let it to another one); so, we should wait with adding this patches till (1) we agree and (2) it is complete remark: also, it's dangerous to add patched before a decent decission/interface is dediced upon; once it's in, we cannot change it any more Hans ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=469&group_id=106

1 0

[ pdftex-Patches-438 ] \pdfsavepos in DVI mode
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #438, was opened at 2005-10-16 23:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106 Category: Positioning >Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Hartmut Henkel (hhenkel) Summary: \pdfsavepos in DVI mode Initial Comment: \pdfsavepos in DVI mode Hello, using \pdfsavepos in a package of mine (tabularht) I was wondering, why \pdfsavepos is not allowed to work in DVI mode. \pdfsavepos in PDF mode is based on cur_h and cur_v, both coming from the DVI frontend. The only difference I found is that the PDF format and pdfTeX's PDF mode know about page dimensions. Thus the directions of the axes are the same for the PDF format and the values of \pdfsavepos (\pdflastxpos, \pdflastypos). Origin: lower left corner horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp The DVI case doesn't know about page dimensions, thus I suggest using cur_h=0 and cur_v=0 as origin. It is the left upper corner of the box that is being shipped out. Origin: left upper corner of the box horizontal axis: values increasing from left to right vertical axis: values increasing from bottom to top unit: sp Thus the absolute values differ in both modes and I don't see that this can be avoided. However, if the application uses a reference point then the relative values are exactly the same. The attachted patch enables and implements \pdfsavepos for the DVI mode. It also contains the patch for bug 437 (Two \immediate cancel themselves). Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> ---------------------------------------------------------------------- Comment By: Heiko Oberdiek (oberdiek) Date: 2005-10-17 13:39 Message: Logged In: YES user_id=1276 Hello, I have now extended the patch: \pdfpagewidth/height are now used for the page dimensions. Also the funny DVI origin offset of 1in is taken into account. Thus the values in DVI and PDF mode are the same. The exception is \pdf{h,v}origin. If the value is not 1in, then the values differ in DVI and PDF mode. However, also the DVI and PDF output will differ in this case. Thus the different values are then ok, I think. If someone wants to have the same values, he just sets \pdfpage{width,height} and let \pdf{h,v}origin untouched. Hartmut Henkel wrote: > to give page dimension info for pdftex also in > DVI mode, one could implement the standard > \special{papersize=x,y} also in pdftex (parallel > to \pdfpagewidth/height), so that it would be > scanned, and also go into the DVI file. Would > this help? I think, not really: * Scanning of \specials are done in PDF mode already, but here it is not really necessary, the current drivers know about \pdfpage{width,height}. * In DVI mode, the scanning of \special's contents must then be added to set \pdfpage{width,height}. But who needs this actually? * Relative positioning with \pdfsavepos works with or without the correct page size information. * Absolute positioning is more difficult in use (If you are somewhere in a box, how do you want to apply absolute positions?) * If someone insist on absolute positioning, he will probably not rely on an accidentally issued \special{papersize=...}. He will probably make sure, that the papersize information is set and then he can also set \pdfpage{width,height}. Yours sincerely Heiko <oberdiek(a)uni-freiburg.de> PS: The name of the patch file is now "v2-pdftex.ch.diff". And I have removed the patch of fixed bug 437. ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-17 00:16 Message: Logged In: YES user_id=929 to give page dimension info for pdftex also in DVI mode, one could implement the standard \special{papersize=x,y} also in pdftex (parallel to \pdfpagewidth/height), so that it would be scanned, and also go into the DVI file. Would this help? Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=438&group_id=106

1 0

[ pdftex-Patches-434 ] Remove queued map item handling
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #434, was opened at 2005-10-13 01:08 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106 Category: Fonts >Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Taco Hoekwater (taco) Summary: Remove queued map item handling Initial Comment: Remove queued map item handling from mapfile.c ============================================== Formerly all items from \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} were queued up in a list until the next font was selected; then the whole list was processed, e. g. all queued mapfiles or maplines read in. When one gave \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-=, the pending list was cleared. The only practical use for this was to prevent reading in the default mapfile. But this can be done simpler, without queuing. With this patch all \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} requests are processed completely and immediately without queuing, which means that if e. g. a \pdfmapfile{+-=mapfile} primitive is scanned, the mapfile will be read in right away. This happens independently from selecting a font. When \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} is scanned, and there is a default mapfile, it is read first and then the mapfile. Reading of the default mapfile can be disabled by \pdfmapfile{} or \pdfmapline{} or \pdfmapfile{mapfile} or \pdfmapline{mapline} without +-= as long as the default mapfile hasn't already been read in. Latest when the first font is requested, the default mapfile will be read, if this hasn't already been disabled by the mentioned primitives. Apart from possibly reading the default mapfile, there is no other action when a font is requested, since the \pdfmapfile{+-=mapfile} or \pdfmapline{+-=mapline} primitives have already acted right away when they were called. The effects of this patch are the following: * Initial mapfile reading still can be blocked in the usual way. * The difficult to describe queuing mechanism has gone, code gets simpler. * Mapfile reading happens directly by the primitives. * Therefore it's possible to use \pdfretval with the primitives, to check success of the mapfile/line reading (not yet implemented). * As the return value is connected to the \pdfmapfile or \pdfmapline call, one can easier implement other map setting primitives and give them return values. This was not possible before, as the queuing was inbetween. * For any standard use, the patch should be compatible to the former queuing method. The mapfile.c is a patched version of the mapfile.c from Thanh's subfont patch pdftex-20050924.patch.gz for pdftex-1.30.3. Hope it doesn't sound too messy :-) For discussion. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=434&group_id=106

1 0

[ pdftex-Patches-432 ] Rules in a PDF qQ group
by noreply＠sarovar.org 27 Feb '06

27 Feb '06

Patches item #432, was opened at 2005-10-06 21:01 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106 Category: Positioning >Group: v1.40.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Hartmut Henkel (hhenkel) Assigned to: Hans Hagen (hagen) Summary: Rules in a PDF qQ group Initial Comment: Put rules with their positioning on the page inside a qQ group. Should make \pdfliteral page {...} behave consistently after text or rules or images, as then any positioning starts from the PDF origin; no delta-positioning anymore. It's already being tested in pdfluatex. Just to have it at sarovar... Testing welcome, particularily with text and graphics transforms by graphicx package, to spot backward incompatibilities, if any... Regards, Hartmut ---------------------------------------------------------------------- Comment By: Hartmut Henkel (hhenkel) Date: 2005-10-09 15:07 Message: Logged In: YES user_id=929 Update pdf_set_origin_temp: Now has (h, v) parameters. Regards, Hartmut ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=432&group_id=106

1 0