July 2005 - ntg-pdftex - NTG Mailing Lists

[ 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

[ pdftex-Patches-387 ] writeenc.c tidied up
by noreply＠sarovar.org 11 Jul '05

11 Jul '05

Patches item #387, was opened at 2005-07-11 22:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=387&group_id=106 Category: Fonts Group: v1.30.0 >Status: Closed >Resolution: Accepted Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: writeenc.c tidied up Initial Comment: minor changes make writeenc.c: Removed linked list from add_enc(), not needed anymore since \pdfmovechars are obsolete. Rewrote enc_free() correspondingly. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2005-07-12 00:11 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=387&group_id=106

1 0

[ pdftex-Patches-387 ] writeenc.c tidied up
by noreply＠sarovar.org 11 Jul '05

11 Jul '05

Patches item #387, was opened at 2005-07-11 22:52 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=387&group_id=106 Category: Fonts Group: v1.30.0 Status: Open Resolution: None Priority: 3 Submitted By: Hartmut Henkel (hhenkel) Assigned to: The Thanh Han (hanthethanh) Summary: writeenc.c tidied up Initial Comment: minor changes make writeenc.c: Removed linked list from add_enc(), not needed anymore since \pdfmovechars are obsolete. Rewrote enc_free() correspondingly. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=387&group_id=106

1 0

kerning
by Hans Hagen 11 Jul '05

11 Jul '05

Hi, Given those future font capabilities of pdftex (thanh: what happened with your construct fonts on the fly feature?), i wonder if it is possible to add something \kernfont\somefont <char code 1> <charcode 2> <dimen> Take for instance: http:\\www.pdftex.org here the \\ may come out pretty spaced, and space can be saved by something: \def\url#1{\begingroup\kernfont\font `\ `\ -.2em\relax#1\endgroup} (i soppose that something like this woudl be possible with thanhs new runtime font feature anyway) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

3 6

[ 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 10 Jul '05

10 Jul '05

Bugs item #384, was opened at 2005-07-10 09: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: Open Resolution: None 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 21: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 14: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 14: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

2 1

backslash in \pdfpagesattr
by Pawel Jackowski 10 Jul '05

10 Jul '05

Hi, I've noticed by accident that if there is a backslash in \pdfpagesattr toks, /Pages object is not created at all. \catcode`\/=0 \catcode`\\=12 /pdfpagesattr={\}?/end Doesn't hurt, since backslash is rather pointless in /Pages dict (?), but nothing like that happen in \pdfpageattr; backslash is written as is. Planned behaviour or side effect? pdfTeX 1.2, 1.3. Regards, -- Pawe/l Jackowski P.Jackowski(a)gust.org.pl

2 2