- ntg-pdftex - NTG Mailing Lists

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 18 Jul '05

18 Jul '05

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

3 2

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

17 Jul '05

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

1 0

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

15 Jul '05

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

2 1

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

15 Jul '05

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

4 5

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

14 Jul '05

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

1 0

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

14 Jul '05

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

1 0

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

12 Jul '05

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

1 0

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

12 Jul '05

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

1 0

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

12 Jul '05

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

1 0