- ntg-pdftex - NTG Mailing Lists

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 01 Oct '07

01 Oct '07

Bugs item #741, was opened at 2007-03-02 10:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-10-01 09:34 Message: Logged In: YES user_id=4699 After adding /Group << /CS /DeviceRGB /Type /Group /S /Transparency >> to the /Page object in newfile2-1.pdf it displays correctly in Acrobat. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-10-01 08:34 Message: Logged In: YES user_id=421 The attached file newfile2-1.pdf has a copied page group, which as I now know, should be correct. Still, AR8@Linux shows different colours for it and TestSkizze.pdf . ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 08:21 Message: Logged In: YES user_id=3168 > Why is this WONTFIX? Sorry, this bug was once closed when this additional info was not available. -> I reopened this bug. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 08:16 Message: Logged In: YES user_id=3168 Why is this WONTFIX? I mean: > The file TestSkizze.pdf specifies the color blending space > with "/CS /DeviceRGB" in the transparency group. In > the PDF produced by pdftex this has been stripped out. So the bug is that pdftex strips out the color space. If you really think it's WONTFIX, then tell me what is the correct way of specifying the color space so that I can forward this to the Inkscape developers. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-09-30 23:04 Message: Logged In: YES user_id=4699 The file TestSkizze.pdf specifies the color blending space with "/CS /DeviceRGB" in the transparency group. In the PDF produced by pdftex this has been stripped out. When the color space is not specified Acrobat defaults to CMYK. This results in RGB colors being converted to CMYK, blended in CMYK color space, then converted back to RGB. This will produce different results compared to blending the colors in RGB space. This problem was also reported to the cairo list: http://lists.cairographics.org/archives/cairo/2007-September/011471.html ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-04 05:11 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-04 01:18 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 22:46 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 22:35 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 22:27 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 10:35 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 01 Oct '07

01 Oct '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-10-01 01:04 Message: Logged In: YES user_id=421 The attached file newfile2-1.pdf has a copied page group, which as I now know, should be correct. Still, AR8@Linux shows different colours for it and TestSkizze.pdf . ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:51 Message: Logged In: YES user_id=3168 > Why is this WONTFIX? Sorry, this bug was once closed when this additional info was not available. -> I reopened this bug. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:46 Message: Logged In: YES user_id=3168 Why is this WONTFIX? I mean: > The file TestSkizze.pdf specifies the color blending space > with "/CS /DeviceRGB" in the transparency group. In > the PDF produced by pdftex this has been stripped out. So the bug is that pdftex strips out the color space. If you really think it's WONTFIX, then tell me what is the correct way of specifying the color space so that I can forward this to the Inkscape developers. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-09-30 15:34 Message: Logged In: YES user_id=4699 The file TestSkizze.pdf specifies the color blending space with "/CS /DeviceRGB" in the transparency group. In the PDF produced by pdftex this has been stripped out. When the color space is not specified Acrobat defaults to CMYK. This results in RGB colors being converted to CMYK, blended in CMYK color space, then converted back to RGB. This will produce different results compared to blending the colors in RGB space. This problem was also reported to the cairo list: http://lists.cairographics.org/archives/cairo/2007-September/011471.html ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-03 19:41 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 01 Oct '07

01 Oct '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:51 Message: Logged In: YES user_id=3168 > Why is this WONTFIX? Sorry, this bug was once closed when this additional info was not available. -> I reopened this bug. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:46 Message: Logged In: YES user_id=3168 Why is this WONTFIX? I mean: > The file TestSkizze.pdf specifies the color blending space > with "/CS /DeviceRGB" in the transparency group. In > the PDF produced by pdftex this has been stripped out. So the bug is that pdftex strips out the color space. If you really think it's WONTFIX, then tell me what is the correct way of specifying the color space so that I can forward this to the Inkscape developers. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-09-30 15:34 Message: Logged In: YES user_id=4699 The file TestSkizze.pdf specifies the color blending space with "/CS /DeviceRGB" in the transparency group. In the PDF produced by pdftex this has been stripped out. When the color space is not specified Acrobat defaults to CMYK. This results in RGB colors being converted to CMYK, blended in CMYK color space, then converted back to RGB. This will produce different results compared to blending the colors in RGB space. This problem was also reported to the cairo list: http://lists.cairographics.org/archives/cairo/2007-September/011471.html ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-03 19:41 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 01 Oct '07

01 Oct '07

Bugs item #741, was opened at 2007-03-02 00:50 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- >Comment By: Uwe Stöhr (stoehr) Date: 2007-10-01 00:46 Message: Logged In: YES user_id=3168 Why is this WONTFIX? I mean: > The file TestSkizze.pdf specifies the color blending space > with "/CS /DeviceRGB" in the transparency group. In > the PDF produced by pdftex this has been stripped out. So the bug is that pdftex strips out the color space. If you really think it's WONTFIX, then tell me what is the correct way of specifying the color space so that I can forward this to the Inkscape developers. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-09-30 15:34 Message: Logged In: YES user_id=4699 The file TestSkizze.pdf specifies the color blending space with "/CS /DeviceRGB" in the transparency group. In the PDF produced by pdftex this has been stripped out. When the color space is not specified Acrobat defaults to CMYK. This results in RGB colors being converted to CMYK, blended in CMYK color space, then converted back to RGB. This will produce different results compared to blending the colors in RGB space. This problem was also reported to the cairo list: http://lists.cairographics.org/archives/cairo/2007-September/011471.html ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-03 19:41 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-03 15:48 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 13:16 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 13:05 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 12:57 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 01:05 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Patches-871 ] Synchronization: pdfsync.sty embedded (1)
by noreply＠sarovar.org 01 Oct '07

01 Oct '07

Patches item #871, was opened at 2007-09-30 10:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106 Category: User interaction Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Martin Schröder (oneiros) Summary: Synchronization: pdfsync.sty embedded (1) Initial Comment: To the administrator, please remove the preceding patch submission The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf PS: I have problems with my connection ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-10-01 00:00 Message: Logged In: YES user_id=421 You didn't attach Synchronize 2.zip yet... ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:10 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:09 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106

1 0

[ pdftex-Feature Requests-718 ] Request of pdfsync
by noreply＠sarovar.org 30 Sep '07

30 Sep '07

Feature Requests item #718, was opened at 2007-01-01 23:27 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Juan Luis Varona (jlvm) Assigned to: The Thanh Han (hanthethanh) Summary: Request of pdfsync Initial Comment: The syncronization between the .tex and the .pdf files is veeeeeery useful. It is not necessary to explain it. Now, there are some tools to do it, but they are far of being good enough. For instance, pdfsync makes some work, but it has a lot of problems. Of instance, the output is different with or without pdfsync. I have read in TUGboat that, perhaps in the near future, pdfsync can be integrated en pdftex itself and improved. I request to do it as soon as possible. Yours sincerely, Juan L. Varona jvarona(a)unirioja.es ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:28 Message: Logged In: YES user_id=4698 I have posted a patch that works for both dvi and pdf output mode. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-29 21:22 Message: Logged In: NO The output is also different with or without -src-specials in DVI mode. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-29 21:03 Message: Logged In: YES user_id=421 You didn't attach any file. :-{ Also please login before commenting. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-29 20:53 Message: Logged In: NO After some work with hanthethanh , here is a patch of pdftex 1.40.4 that would do the job reasonably well. The attached file is a zip archive containing the patch, a demonstration pdf output and some explanations. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-30 13:39 Message: Logged In: YES user_id=710 I am working on this, so I have assigned this item to myself. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-10 14:56 Message: Logged In: NO I second that strongly. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106

1 0

[ pdftex-Patches-871 ] Synchronization: pdfsync.sty embedded (1)
by noreply＠sarovar.org 30 Sep '07

30 Sep '07

Patches item #871, was opened at 2007-09-30 10:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106 Category: User interaction Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Martin Schröder (oneiros) Summary: Synchronization: pdfsync.sty embedded (1) Initial Comment: To the administrator, please remove the preceding patch submission The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf PS: I have problems with my connection ---------------------------------------------------------------------- >Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:10 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:09 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106

1 0

[ pdftex-Patches-871 ] Synchronization: pdfsync.sty embedded (1)
by noreply＠sarovar.org 30 Sep '07

30 Sep '07

Patches item #871, was opened at 2007-09-30 10:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106 Category: User interaction Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Martin Schröder (oneiros) Summary: Synchronization: pdfsync.sty embedded (1) Initial Comment: To the administrator, please remove the preceding patch submission The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf PS: I have problems with my connection ---------------------------------------------------------------------- >Comment By: Jerome LAURENS (jlaurens) Date: 2007-09-30 23:09 Message: Logged In: YES user_id=4698 Synchronize 2.zip is a version extending the previous one. Now synchronization works the same for both dvi and pdf output modes. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106

1 0

[ pdftex-Patches-870 ] Synchronization: pdfsync.sty embedded
by noreply＠sarovar.org 30 Sep '07

30 Sep '07

Patches item #870, was opened at 2007-09-30 10:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=870&group_id=106 Category: None Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Nobody (None) Summary: Synchronization: pdfsync.sty embedded Initial Comment: The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=870&group_id=106

1 0

[ pdftex-Bugs-741 ] wrong colors for included PDF-images (page groups)
by noreply＠sarovar.org 30 Sep '07

30 Sep '07

Bugs item #741, was opened at 2007-03-02 10:20 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106 Category: PDF inclusion Group: v1.30.0 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Uwe Stöhr (stoehr) Assigned to: Martin Schröder (oneiros) Summary: wrong colors for included PDF-images (page groups) Initial Comment: Attached is a PDF 1.4 image. When you include this to a document the output generated by pdfetex 1.30.6 the images looks different: The colors are much darker, see attached PDF result. ---------------------------------------------------------------------- Comment By: Adrian Johnson (ajohnson) Date: 2007-09-30 23:04 Message: Logged In: YES user_id=4699 The file TestSkizze.pdf specifies the color blending space with "/CS /DeviceRGB" in the transparency group. In the PDF produced by pdftex this has been stripped out. When the color space is not specified Acrobat defaults to CMYK. This results in RGB colors being converted to CMYK, blended in CMYK color space, then converted back to RGB. This will produce different results compared to blending the colors in RGB space. This problem was also reported to the cairo list: http://lists.cairographics.org/archives/cairo/2007-September/011471.html ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-04 05:11 Message: Logged In: YES user_id=3168 > To my eye the Harlequin results are the same for both > file, Yes and the result is correct. > while Jaws has to different results. In my eyes the Jaws results are identical but wrong. So it seems that pdftex is not the problem here, but it would be nice if pdftex could handle page groups in one of the next releases: >"PDF inclusion: Page Group detected which pdfTeX can't > handle. Ignoring it." So I'm not sure to close this bug or mark it as enhancement. Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-04 01:18 Message: Logged In: YES user_id=421 I've attached the results of two professional RIPs: Global Graphics Jaws & Harlequin. To my eye the Harlequin results are the same for both file, while Jaws has to different results. :-{ ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 22:46 Message: Logged In: YES user_id=421 Your document is using Page Groups (see PDF Reference 7.3.6). Including pdfs that use this is a grey area; see the notes in NEWS and pdftoepdf.cc. It works most of the times and with most RIPs. I'll look into it again, but I don't have much hope. Btw: pdftex warns you: "PDF inclusion: Page Group detected which pdfTeX can't handle. Ignoring it." ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 22:35 Message: Logged In: YES user_id=3168 > problem in AR7 - but only there. But how could this be a bug in Acrobat when Adobe set the standards? Why is this correctly shown before the pdftex-run. The display is the same here in Acrobat 5 - 8 so I think they would have fixed it when it's a bug since Acrobat 5. Hmm but OK, when I open the result with GSview besides the GS bug, the color tones are correctly be displayed. So close this bug report again, when you are sure that pdftex follows here exactly the PDF-specification. ---------------------------------------------------------------------- Comment By: Uwe Stöhr (stoehr) Date: 2007-03-02 22:27 Message: Logged In: YES user_id=3168 > It's a bug in AR; No! Acrobat is correct: I created this image with Inkscape 0.45 and exported it the as PDF. I designed e.g. the green as light green. And Acrobat 7 and 8 shows this exactly as designed while the pdftex result has wrong color tones, see the attached screenshots. (Ghostscript is btw. not able to render the PDF-image correctly - I reported this to the GS people who confirmed it.) ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-03-02 10:35 Message: Logged In: YES user_id=421 You don't say it, but I see the same problem in AR7 - but only there. It's a bug in AR; try kpdf or ghostscript instead. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=741&group_id=106

1 0

[ pdftex-Patches-871 ] Synchronization: pdfsync.sty embedded (1)
by noreply＠sarovar.org 30 Sep '07

30 Sep '07

Patches item #871, was opened at 2007-09-30 10:56 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106 Category: User interaction Group: v1.40.0 Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Martin Schröder (oneiros) Summary: Synchronization: pdfsync.sty embedded (1) Initial Comment: To the administrator, please remove the preceding patch submission The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf PS: I have problems with my connection ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=871&group_id=106

1 0

[ pdftex-Patches-870 ] Synchronization: pdfsync.sty embedded
by noreply＠sarovar.org 30 Sep '07

30 Sep '07

Patches item #870, was opened at 2007-09-30 10:28 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=870&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Nobody (None) Summary: Synchronization: pdfsync.sty embedded Initial Comment: The purpose is to implement some extensions very useful for synchronization, both forwards and backwards. Synchronization is the ability for a text editor and a pdf viewer to work together, displaying the same thing at the same time. For example, a text editor can ask a pdf viewer to display and outline the character in the output corresponding to the character under the cursor. Attached is a zip file containing diff against version 1.40.4, explanations and demonstrations in synchronize.readme/synchronize+frames.pdf ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=870&group_id=106

1 0

[ pdftex-Feature Requests-718 ] Request of pdfsync
by noreply＠sarovar.org 29 Sep '07

29 Sep '07

Feature Requests item #718, was opened at 2007-01-02 03:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Juan Luis Varona (jlvm) Assigned to: The Thanh Han (hanthethanh) Summary: Request of pdfsync Initial Comment: The syncronization between the .tex and the .pdf files is veeeeeery useful. It is not necessary to explain it. Now, there are some tools to do it, but they are far of being good enough. For instance, pdfsync makes some work, but it has a lot of problems. Of instance, the output is different with or without pdfsync. I have read in TUGboat that, perhaps in the near future, pdfsync can be integrated en pdftex itself and improved. I request to do it as soon as possible. Yours sincerely, Juan L. Varona jvarona(a)unirioja.es ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-30 00:52 Message: Logged In: NO The output is also different with or without -src-specials in DVI mode. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-30 00:33 Message: Logged In: YES user_id=421 You didn't attach any file. :-{ Also please login before commenting. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-30 00:23 Message: Logged In: NO After some work with hanthethanh , here is a patch of pdftex 1.40.4 that would do the job reasonably well. The attached file is a zip archive containing the patch, a demonstration pdf output and some explanations. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-30 17:09 Message: Logged In: YES user_id=710 I am working on this, so I have assigned this item to myself. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-10 18:26 Message: Logged In: NO I second that strongly. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106

1 0

[ pdftex-Feature Requests-718 ] Request of pdfsync
by noreply＠sarovar.org 29 Sep '07

29 Sep '07

Feature Requests item #718, was opened at 2007-01-01 23:27 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Juan Luis Varona (jlvm) Assigned to: The Thanh Han (hanthethanh) Summary: Request of pdfsync Initial Comment: The syncronization between the .tex and the .pdf files is veeeeeery useful. It is not necessary to explain it. Now, there are some tools to do it, but they are far of being good enough. For instance, pdfsync makes some work, but it has a lot of problems. Of instance, the output is different with or without pdfsync. I have read in TUGboat that, perhaps in the near future, pdfsync can be integrated en pdftex itself and improved. I request to do it as soon as possible. Yours sincerely, Juan L. Varona jvarona(a)unirioja.es ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-09-29 21:03 Message: Logged In: YES user_id=421 You didn't attach any file. :-{ Also please login before commenting. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-29 20:53 Message: Logged In: NO After some work with hanthethanh , here is a patch of pdftex 1.40.4 that would do the job reasonably well. The attached file is a zip archive containing the patch, a demonstration pdf output and some explanations. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-30 13:39 Message: Logged In: YES user_id=710 I am working on this, so I have assigned this item to myself. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-10 14:56 Message: Logged In: NO I second that strongly. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106

1 0

[ pdftex-Feature Requests-718 ] Request of pdfsync
by noreply＠sarovar.org 29 Sep '07

29 Sep '07

Feature Requests item #718, was opened at 2007-01-02 03:57 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Juan Luis Varona (jlvm) Assigned to: The Thanh Han (hanthethanh) Summary: Request of pdfsync Initial Comment: The syncronization between the .tex and the .pdf files is veeeeeery useful. It is not necessary to explain it. Now, there are some tools to do it, but they are far of being good enough. For instance, pdfsync makes some work, but it has a lot of problems. Of instance, the output is different with or without pdfsync. I have read in TUGboat that, perhaps in the near future, pdfsync can be integrated en pdftex itself and improved. I request to do it as soon as possible. Yours sincerely, Juan L. Varona jvarona(a)unirioja.es ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-30 00:23 Message: Logged In: NO After some work with hanthethanh , here is a patch of pdftex 1.40.4 that would do the job reasonably well. The attached file is a zip archive containing the patch, a demonstration pdf output and some explanations. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2007-07-30 17:09 Message: Logged In: YES user_id=710 I am working on this, so I have assigned this item to myself. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-05-10 18:26 Message: Logged In: NO I second that strongly. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=718&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-23 02:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-09-23 20:19 Message: Logged In: YES user_id=421 Please continue the discussion on the pdftex mailing list. ---------------------------------------------------------------------- Comment By: George N. White III (gnwiii) Date: 2007-09-23 20:16 Message: Logged In: YES user_id=4692 So path searching is not slow and CPU usage is slow, which indicates waiting for I/O. This could be loading files (.pool file, format, ...), console output, or file output. You didn't mention of whether files are on local disk or network, USB, etc. 1. on general principles, I'd do a disk cleanup and run chkdsk /f to make sure disks are OK. 2. check for signs of trouble in the event viewer. 3. run "pdftex -recorder story" and and "pdflatex -recorder sample2e" to check for files in unexpected locations, especially network or USB drives. 4. try a different terminal program -- there have been reports of widely varying performance between different terminals, remote ssh, etc. ---------------------------------------------------------------------- Comment By: Theo Hopman (thopman) Date: 2007-09-23 18:34 Message: Logged In: YES user_id=4690 kpsewhich shows no noticeable delay. pdftex 1.40 was slow when building formats. While pdftex is starting (and delaying), the system idle process is using 90%+ of CPU. The memory usage of pdftex does grow slowly, then jumps once it stops delaying. I don't think the problem is with search paths, because I didn't change these when I upgraded, and besides, kpathsea seems to be plenty fast still. THeo ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-23 13:56 Message: Logged In: NO Is kpathsea also slow? Was pdftex 1.40 slow when building formats? What do you see in the Windows process viewer (there are two CPU columns, one shows cumulative CPU time and the other current CPU usage, by default only one is shown)? For me, when apps are slow to start it is usually mcafee that is using 98% of CPU. Matlab takes over 2 minutes to start with McAfee running, but only a few seconds with McAfee configured to ignore the Matlab directory. Are there network directories in the search path? I use Win32 at work were the users "HOME" directory is on a network drive, but many users systems don't correctly negotiate the duplex setting with the ethernet switch. When network access is slow, running the network "repair" tool (sometimes takes several attempts) will (usually, eventually) make things better (linux has mii-tool where I can check the duplex setting and force it to full). If "man pdftex" is working, look for: -recorder Enable the filename recorder. This leaves a trace of the files opened for input and output in a file with extension .fls. This still omits a few files, but may give you a hint. Have you tried simplifying the search paths in texmf.cnf? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-22 21:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- Comment By: George N. White III (gnwiii) Date: 2007-09-23 15:16 Message: Logged In: YES user_id=4692 So path searching is not slow and CPU usage is slow, which indicates waiting for I/O. This could be loading files (.pool file, format, ...), console output, or file output. You didn't mention of whether files are on local disk or network, USB, etc. 1. on general principles, I'd do a disk cleanup and run chkdsk /f to make sure disks are OK. 2. check for signs of trouble in the event viewer. 3. run "pdftex -recorder story" and and "pdflatex -recorder sample2e" to check for files in unexpected locations, especially network or USB drives. 4. try a different terminal program -- there have been reports of widely varying performance between different terminals, remote ssh, etc. ---------------------------------------------------------------------- Comment By: Theo Hopman (thopman) Date: 2007-09-23 13:34 Message: Logged In: YES user_id=4690 kpsewhich shows no noticeable delay. pdftex 1.40 was slow when building formats. While pdftex is starting (and delaying), the system idle process is using 90%+ of CPU. The memory usage of pdftex does grow slowly, then jumps once it stops delaying. I don't think the problem is with search paths, because I didn't change these when I upgraded, and besides, kpathsea seems to be plenty fast still. THeo ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-23 08:56 Message: Logged In: NO Is kpathsea also slow? Was pdftex 1.40 slow when building formats? What do you see in the Windows process viewer (there are two CPU columns, one shows cumulative CPU time and the other current CPU usage, by default only one is shown)? For me, when apps are slow to start it is usually mcafee that is using 98% of CPU. Matlab takes over 2 minutes to start with McAfee running, but only a few seconds with McAfee configured to ignore the Matlab directory. Are there network directories in the search path? I use Win32 at work were the users "HOME" directory is on a network drive, but many users systems don't correctly negotiate the duplex setting with the ethernet switch. When network access is slow, running the network "repair" tool (sometimes takes several attempts) will (usually, eventually) make things better (linux has mii-tool where I can check the duplex setting and force it to full). If "man pdftex" is working, look for: -recorder Enable the filename recorder. This leaves a trace of the files opened for input and output in a file with extension .fls. This still omits a few files, but may give you a hint. Have you tried simplifying the search paths in texmf.cnf? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-22 20:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- >Comment By: Theo Hopman (thopman) Date: 2007-09-23 12:34 Message: Logged In: YES user_id=4690 kpsewhich shows no noticeable delay. pdftex 1.40 was slow when building formats. While pdftex is starting (and delaying), the system idle process is using 90%+ of CPU. The memory usage of pdftex does grow slowly, then jumps once it stops delaying. I don't think the problem is with search paths, because I didn't change these when I upgraded, and besides, kpathsea seems to be plenty fast still. THeo ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-23 07:56 Message: Logged In: NO Is kpathsea also slow? Was pdftex 1.40 slow when building formats? What do you see in the Windows process viewer (there are two CPU columns, one shows cumulative CPU time and the other current CPU usage, by default only one is shown)? For me, when apps are slow to start it is usually mcafee that is using 98% of CPU. Matlab takes over 2 minutes to start with McAfee running, but only a few seconds with McAfee configured to ignore the Matlab directory. Are there network directories in the search path? I use Win32 at work were the users "HOME" directory is on a network drive, but many users systems don't correctly negotiate the duplex setting with the ethernet switch. When network access is slow, running the network "repair" tool (sometimes takes several attempts) will (usually, eventually) make things better (linux has mii-tool where I can check the duplex setting and force it to full). If "man pdftex" is working, look for: -recorder Enable the filename recorder. This leaves a trace of the files opened for input and output in a file with extension .fls. This still omits a few files, but may give you a hint. Have you tried simplifying the search paths in texmf.cnf? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-23 06:00 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2007-09-23 17:26 Message: Logged In: NO Is kpathsea also slow? Was pdftex 1.40 slow when building formats? What do you see in the Windows process viewer (there are two CPU columns, one shows cumulative CPU time and the other current CPU usage, by default only one is shown)? For me, when apps are slow to start it is usually mcafee that is using 98% of CPU. Matlab takes over 2 minutes to start with McAfee running, but only a few seconds with McAfee configured to ignore the Matlab directory. Are there network directories in the search path? I use Win32 at work were the users "HOME" directory is on a network drive, but many users systems don't correctly negotiate the duplex setting with the ethernet switch. When network access is slow, running the network "repair" tool (sometimes takes several attempts) will (usually, eventually) make things better (linux has mii-tool where I can check the duplex setting and force it to full). If "man pdftex" is working, look for: -recorder Enable the filename recorder. This leaves a trace of the files opened for input and output in a file with extension .fls. This still omits a few files, but may give you a hint. Have you tried simplifying the search paths in texmf.cnf? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[ pdftex-Support Requests-869 ] pdflatex slow to start on Cygwin
by noreply＠sarovar.org 23 Sep '07

23 Sep '07

Support Requests item #869, was opened at 2007-09-22 20:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Theo Hopman (thopman) Assigned to: Nobody (None) Summary: pdflatex slow to start on Cygwin Initial Comment: I use Cygwin on WinXP pro, with teTex 3.0 installed. I recently built pdftex 1.40 (which went well), manually replaced the old binaries of pdftex, and rebuilt the various formats using fmtutil. Now, however, pdflatex starts up only after a considerable delay (anywhere from a couple of seconds up to half a minute). While pdflatex sits there looking like its doing nothing, it also responds slowly to interrupt (^C) signals. Why might this be? `pdflatex --version`, by contrast, is instantaneous, so the issue is likely something to do with searching or loading formats. THeo ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=869&group_id=106

1 0

[Fwd: Re: \suppressfontnotfounderror (Re: \nofontnotfounderror patch)]
by Taco Hoekwater 18 Sep '07

18 Sep '07

FYI (Jonathan is on the discards list) Cheers, Taco -------- Original Message -------- Subject: Re: \suppressfontnotfounderror (Re: [NTG-pdftex] \nofontnotfounderror patch) Date: Mon, 17 Sep 2007 17:27:31 +0100 From: Jonathan Kew <jonathan_kew(a)sil.org> To: Taco Hoekwater <taco(a)elvenkind.com> CC: pdfTeX developers list <ntg-pdftex(a)ntg.nl>, Will Robertson <wspr81(a)gmail.com> References: <46EE77A5.2030205(a)elvenkind.com> <46EE9ED9.7080000(a)elvenkind.com> OK, this is now included in the xetex svn sources as well, with the name \suppressfontnotfounderror. Thanks, JK On 17 Sep 2007, at 4:35 pm, Taco Hoekwater wrote: > > Hi, > > Phil Taylor and I just had an email exchange about the name of > the primitive, and after a few messages he convinced me that it > is better not to have a double negation in the name because > it is not unlikely that will not prevent people from becoming > confused. So, here is an updated patch with the new name: > > \suppressfontnotfounderror > > Best wishes, > Taco

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 18 Sep '07

18 Sep '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 Category: Primitives Group: v1.50.0 Status: Open Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Martin Schröder (oneiros) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2007-09-18 08:10 Message: Logged In: YES user_id=1608 Well, at least it does not affect the tex user directly: there is a stream of garbage on the screen and that looks ugly, but there is no error interaction, and the system-level return value of pdftex is unaffected. I don't know if there is a clean way to control mktextfm cs, but if it can be done, that would be a nice addition to the web2c change file. ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2007-09-17 21:53 Message: Logged In: YES user_id=421 IMHO it works only somuch, but that may be due to kpathsea: > pdftex test.tex This is pdfTeX, Version 3.141592-1.50.0-alpha-20070917 (Web2C 7.5.6) entering extended mode (./test.texkpathsea: Running mktextfm cmr-junk mktextfm: Running mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk This is METAFONT, Version 2.71828 (Web2C 7.5.4) kpathsea: Running mktexmf cmr-junk ! I can't find file `cmr-junk'. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Please type another input file name ! Emergency stop. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Transcript written on mfput.log. grep: cmr-junk.log: Datei oder Verzeichnis nicht gefunden mktextfm: `mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk' failed to make cmr-junk.tfm. kpathsea: Appending font creation commands to missfont.log. Font cmr-junk not found ) No pages of output. Transcript written on test.log. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 17 Sep '07

17 Sep '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 Category: Primitives Group: v1.50.0 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Taco Hoekwater (taco) >Assigned to: Martin Schröder (oneiros) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2007-09-17 21:53 Message: Logged In: YES user_id=421 IMHO it works only somuch, but that may be due to kpathsea: > pdftex test.tex This is pdfTeX, Version 3.141592-1.50.0-alpha-20070917 (Web2C 7.5.6) entering extended mode (./test.texkpathsea: Running mktextfm cmr-junk mktextfm: Running mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk This is METAFONT, Version 2.71828 (Web2C 7.5.4) kpathsea: Running mktexmf cmr-junk ! I can't find file `cmr-junk'. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Please type another input file name ! Emergency stop. <*> ...xmarkr; mag:=1; nonstopmode; input cmr-junk Transcript written on mfput.log. grep: cmr-junk.log: Datei oder Verzeichnis nicht gefunden mktextfm: `mf-nowin -progname=mf \mode:=lexmarkr; mag:=1; nonstopmode; input cmr-junk' failed to make cmr-junk.tfm. kpathsea: Appending font creation commands to missfont.log. Font cmr-junk not found ) No pages of output. Transcript written on test.log. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 17 Sep '07

17 Sep '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 >Category: Primitives >Group: v1.50.0 Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0

[ pdftex-Patches-864 ] \suppressfontnotfounderror patch
by noreply＠sarovar.org 17 Sep '07

17 Sep '07

Patches item #864, was opened at 2007-09-17 17:49 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Taco Hoekwater (taco) Assigned to: Nobody (None) Summary: \suppressfontnotfounderror patch Initial Comment: Attached is a patch for pdftex 1.50 (current trunk) that introduces a new integer parameter named \suppressfontnotfounderror. If this parameter is non-zero, then (pdf)tex will not complain about font metric files that are not found, but silently skip the font assignment, making the requested csname \ifx-equal to \nullfont. The purpose is to allow macro programmers a way to gracefully recover from a missing or differently named font. I am aware there is a trick that uses \batchmode to test for font existance, but the downside of that is that it calls TeX's error() routine, which clobbers the executable's return value. That makes it a no-no in "make"-like environments where the return value of TeX is checked to decide on further actions. This functionality will also be added to the next versions of xetex and luatex (that's why the name does not start with \pdf...). % simple example usage \def\testfont#1{% \font\junk=#1 \ifx\junk\nullfont \message{Font #1 not found} \else \message{Font #1 found} \fi } {\suppressfontnotfounderror=1 \testfont{cmr-junk} } \bye ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=864&group_id=106

1 0