- ntg-pdftex - NTG Mailing Lists

Fwd: [poppler] 2 commits - poppler/GfxFont.cc poppler/GlobalParams.cc poppler/TextOutputDev.cc poppler/TextOutputDev.h poppler/UnicodeTypeTable.cc poppler/UnicodeTypeTable.h poppler/XpdfPluginAPI.cc
by Martin Schröder 10 Jul '11

10 Jul '11

It seems XPDF is now under GPLv2+. :-) Best Martin ---------- Forwarded message ---------- From: Albert Astals Cid <aacid(a)kemper.freedesktop.org> Date: 2011/7/10 Subject: [poppler] 2 commits - poppler/GfxFont.cc poppler/GlobalParams.cc poppler/TextOutputDev.cc poppler/TextOutputDev.h poppler/UnicodeTypeTable.cc poppler/UnicodeTypeTable.h poppler/XpdfPluginAPI.cc To: poppler(a)lists.freedesktop.org poppler/GfxFont.cc | 3 +++ poppler/GlobalParams.cc | 3 +++ poppler/TextOutputDev.cc | 3 +++ poppler/TextOutputDev.h | 3 +++ poppler/UnicodeTypeTable.cc | 3 +++ poppler/UnicodeTypeTable.h | 3 +++ poppler/XpdfPluginAPI.cc | 3 +++ 7 files changed, 21 insertions(+) New commits: commit 214322f3c66a9aad4e2a46f6e305a3dacaa4f8b1 Author: Albert Astals Cid <aacid(a)kde.org> Date: Sun Jul 10 01:20:21 2011 +0100 And 3 years later, Ed has answered :-) Now all our changes are GPLv2+ diff --git a/poppler/GfxFont.cc b/poppler/GfxFont.cc index d80208d..114c797 100644 --- a/poppler/GfxFont.cc +++ b/poppler/GfxFont.cc @@ -10,6 +10,9 @@ // // Modified under the Poppler project - http://poppler.freedesktop.org // +// All changes made under the Poppler project to this file are licensed +// under GPL version 2 or later +//

1 0

[pdftex-Bugs][4316] glyphtounicode.tex contains wrong entries
by pdftex-bugs＠sarovar.org 06 Jun '11

06 Jun '11

Bugs item #4316, was opened at 2010-08-02 02:23 Status: Closed Priority: 3 Submitted By: The Thanh Han (hanthethanh) Assigned to: The Thanh Han (hanthethanh) Summary: glyphtounicode.tex contains wrong entries Category: Fonts Group: None Resolution: Accepted Initial Comment: Date: Sun, 1 Aug 2010 00:39:36 +0100 (BST) From: "Dr. Clea F. Rees" <cfrees(a)imapmail.org> ... should glyphtounicode.tex be using: {precedesequal}{2AAF} {followsequal}{2AB0} rather than mapping these to 227C and 227D? glyphtounicode.tex seems to disagree with both STIX and fontforge, as well as Hirwen. I think 227C and 227D correspond to characters in AMS MS A: {precedesorcurly}{227C} {followsorcurly}{227D} rather than the characters in OMS. ---------------------------------------------------------------------- Comment By: Lev Bishop (levbishop) Date: 2011-06-05 18:45 Message: Where can I get a copy of the improved glyphtounicode.tex? The version in SVN dates to 2007. Google for "eddie kohler glyphtounicode.tex" only returns this bug tracker. ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2010-12-18 21:16 Message: glyphtounicode.tex has been much improved and is being maintained by Eddie Kohler now. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4316&group_id=106

1 0

[pdftex-Bugs][4338] \pdfmdfivesum with keyword file
by pdftex-bugs＠sarovar.org 04 May '11

04 May '11

Bugs item #4338, was opened at 2011-05-04 08:34 Status: Open Priority: 3 Submitted By: Heiko Oberdiek (oberdiek) Assigned to: Nobody (None) Summary: \pdfmdfivesum with keyword file Category: Documentation Group: None Resolution: None Initial Comment: The manual of pdfTeX (2010-11-23, rev. 655) is incomplete for \pdfmdfivesum. It also knows the keyword "file", then <general text> is interpreted as file name and the MD5 checksum is calculated for the data in the file, Example: \pdfmdfivesum file {test.tex} calculates the MD5 checksum for test.tex. Yours sincerely Heiko Oberdiek ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4338&group_id=106

1 0

[pdftex-Support Requests][4337] Text inside lstlisting in generated PDF have extra spaces
by pdftex-supportrequests＠sarovar.org 04 Apr '11

04 Apr '11

Support Requests item #4337, was opened at 2011-04-04 15:06 Status: Open Priority: 3 Submitted By: MaxiM Basunov (mbasunov) Assigned to: Nobody (None) Summary: Text inside lstlisting in generated PDF have extra spaces Category: None Group: None Resolution: None Initial Comment: Hello. In our documents we use lstlisting and PDF, generated with pdflatex, contains extra spaces between characters, so it makes PDF unuseful for copy-paste. Attached files produce following text when copied from PDF: a sdf l i s t i n g /home/ t e s t / t e s t 2 l i n e 2 \\ t e s t \bbb\ t e s t 2 Sample from other document: "1. exported resources configured" when copied to clipboard produce some missed characters: "1. exported resources congured." Please help to solve these issues. Can it be solved with my local settings? PS: Ubuntu 10.10 Maverick. Acrobat Reader 9.4 lyx 1.6.7-1 texlive-latex-base 2009-10 pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) kpathsea version 5.0.0 Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.2.44; using libpng 1.2.44 Compiled with zlib 1.2.3.4; using zlib 1.2.3.4 Compiled with poppler version 0.14.2 Thank you, ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=494&aid=4337&group_id=106

1 0

[pdftex-Bugs][4336] Distorted audio with beamer
by pdftex-bugs＠sarovar.org 02 Apr '11

02 Apr '11

Bugs item #4336, was opened at 2011-04-02 13:53 Status: Open Priority: 3 Submitted By: Ian Finlayson (ian_fin) Assigned to: Nobody (None) Summary: Distorted audio with beamer Category: None Group: None Resolution: None Initial Comment: I've encountered a problem in 1.40.11 that isn't present in 1.40.10. I've been trying to embed audio in Beamer presentations and when I try and play it back in Adobe Reader, in Windows, the audio is distorted. I've tried building the presentation through other methods (latex -> dvips -> ps2pdf) and it works fine, so definitely seems to be an issue with pdflaTeX. Attached an example with the .tex, the original audio and a PDF created through pdflatex and another created by ps2pdf (ps2pdf doesn't embed audio, so you'll need to have it in the same folder as the .pdf) for comparison. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4336&group_id=106

1 0

Fwd: [poppler] [PATCH] Fixup LaTeX composed characters
by Lev Bishop 30 Mar '11

30 Mar '11

> On 25-3-2011 2:40, Martin Schröder wrote: > > FYI. > > Don't ask me what's the problem with our PDF seems to be... > > indeed. > > if we even consider this for luatex, it should be an option that is not > applied by default ... tweaking an included pdf file should never happen > automatically as overlapping can be intentional ... I think the point of the message was not that pdftex should be fixing included files, but that pdftex should not be doing something that the pdf viewers then have to work around. As far as I understand it, the poppler people are complaining that copying accented text out of the pdf doesn't work right, because instead of an "á" character, the file contains "a" and the accent as separate glyphs, correctly positioned to look like if it was an "á", which is fine for viewing, but not for text-extraction. I suspect that this behaviour is too deeply embedded in tex to be easily fixable. Lev -- Lev Bishop Joint Quantum Institute

1 0

Fwd: [poppler] [PATCH] Fixup LaTeX composed characters
by Martin Schröder 25 Mar '11

25 Mar '11

FYI. Don't ask me what's the problem with our PDF seems to be... ---------- Forwarded message ---------- From: Tim Brody <tdb2(a)ecs.soton.ac.uk> Date: 2011/3/25 Subject: [poppler] [PATCH] Fixup LaTeX composed characters To: poppler(a)lists.freedesktop.org Hi All, Attached is a patch to address the previous problem I wrote about with pdflatex-produced PDFs that contain overlapping-diacritics/accents. This patch contains: - a table of diacritic to Unicode combining character code-points - if an overlapping character is detected checks whether the first (in stream-sequence) character is in the table - pops the diacritic off the word - appends the diacritic to the character as a Unicode combining character This does not fix \b{o} or \d{o} because TeX places them on the next line (so aren't detected as overlapping). Yes, this is an issue with pdflatex but there are 100,000s of TeX-produced PDFs for which we don't have source for ... -- All the best, Tim. _______________________________________________ poppler mailing list poppler(a)lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler

2 1

[pdftex-Feature Requests][4333] Provide information about \write18 calls
by pdftex-featurerequests＠sarovar.org 18 Mar '11

18 Mar '11

Feature Requests item #4333, was opened at 2011-03-18 19:15 Status: Open Priority: 3 Submitted By: Martin Scharrer (martin_scharrer) Assigned to: Nobody (None) Summary: Provide information about \write18 calls Category: Interface Improvements (example) Group: None Resolution: None Initial Comment: Further information about \write18 calls should be provided. At the moment \pdfshellescape tells if shell escape is disabled, enabled or restricted in general but no status information is provided for specific \write18 calls. It would be very useful to be able to access the following information: * Was the program executed or disallowed because of restricted mode. In other words: Is the program listed as trusted or not. * Can the program be found? * Return code of the program that is executed. * Quoting specification for the command call. Using this information a package could test if the external program was really successfully executed or not and why and provide appropriate information to the user. References: This topic has been discussed as "Testing success of \write18" on comp.text.tex (http://groups.google.com/group/comp.text.tex/tree/browse_frm/thread/eee73e7…) and TeX.SX (http://tex.stackexchange.com/questions/13226/test-success-of-write18) ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=4333&group_id=106

1 0

[pdftex-Bugs][4332] pdflatex enters endless loop on malformed align-environment in nonstopmode
by pdftex-bugs＠sarovar.org 18 Mar '11

18 Mar '11

Bugs item #4332, was opened at 2011-03-18 13:28 Status: Open Priority: 3 Submitted By: Mike Rofone (mikerofone) Assigned to: Nobody (None) Summary: pdflatex enters endless loop on malformed align-environment in nonstopmode Category: Build process Group: v1.40.1 Resolution: None Initial Comment: On compiling the attached minimal example containing a malformed "align" environment, pdftex seems to enter an endless loop (does not terminate and 100% CPU load) if invoked as pdftex \nonstopmode \input{test.tex} which is how rubber seems to invoke pdftex. If run without nonstopmode, compilation immediately stops at an error prompt (as expected). I do not know if this is an error with the amsmath-package defining the align-environment, but as it looks a little similar to bug #909 ( http://sarovar.org/tracker/?func=detail&atid=493&aid=909&group_id=106 ) I hope that it does fit here. I do not have another LaTeX compiler to test with. Further detail: [mikerofone@ente ~/Desktop]$ pdflatex --version pdfTeX 3.1415926-1.40.11-2.2 (TeX Live 2010/Arch Linux) kpathsea version 6.0.0 Copyright 2010 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.4.5; using libpng 1.4.5 Compiled with zlib 1.2.5; using zlib 1.2.5 Compiled with poppler version 0.16.2 ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4332&group_id=106

1 0

[pdftex-Feature Requests][4328] Avoid the generation of /ID optionally
by pdftex-featurerequests＠sarovar.org 10 Mar '11

10 Mar '11

Feature Requests item #4328, was opened at 2011-03-10 13:24 Status: Open Priority: 3 Submitted By: Jens Mueller (jens) Assigned to: Nobody (None) Summary: Avoid the generation of /ID optionally Category: PDF generation Group: v1.40 Resolution: None Initial Comment: pdftex will always set /ID in the file trailer. But setting it is optional, if /Encrypt is not set (see section 7.5.5 in ISO 32000-1; can be obtained here http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf) Because /ID is always set it will change for each run because the current time is used for generating it. This can be annoying because it makes regeneration of the very same PDF (looking at the file contents) very difficult (see e.g. http://superuser.com/questions/130347/how-do-i-produce-bytewise-consistent-…) I suggest to add a flag to pdftex that allows to disable the generation of \ID. Something like [-no]-id=<value> to disable the generation of \ID or specifying the value on command line. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=496&aid=4328&group_id=106

1 0

[pdftex-Bugs][4327] Letter Beta in certain adobe pdf viewers
by pdftex-bugs＠sarovar.org 15 Feb '11

15 Feb '11

Bugs item #4327, was opened at 2011-02-15 19:06 Status: Open Priority: 3 Submitted By: Lauren Pearce (physics) Assigned to: Nobody (None) Summary: Letter Beta in certain adobe pdf viewers Category: None Group: None Resolution: None Initial Comment: Hello all- I've discovered an odd problem with documents compiled using pdflatex that appears when using several different pdf viewers on ereaders. The letter beta is printed on top of the previous letter. This happens in: 1) The adobe pdf viewer on the Pocketbook 902 and 903 2) The adobe pdf viewer on the Entourage Edge 3) The pdf viewer on the Sony ereaders 4) The Kindle pdf viewer (both the regular Kindle and the Kindle DX) As for the last two, I don't know if they are made from the adobe reader toolkit, while I believe the first two are. However, the letter beta appears fine when viewed with adobe reader on either linux or windows, and with evince on linux. This would suggest that perhaps the problem is in the adobe reader toolkit being used for these devices; but on the other hand, if I compile to postscript and then convert to pdf, then the letter beta is fine on them. So that would suggest to me that there's an issue with how the letter is handled in pdflatex that is only showing up in these viewers. I'm aware that it may be that none of the developers have an ereader to test files on; I'm more than willing to test files on my kindle dx (and ask others with other devices to test, although I can't promise they will) if you need someone to. I can also upload screen shots if you need. Thank you very much for your help! Please let me know if I can help in any way. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4327&group_id=106

1 0

[pdftex-Bugs][4326] pdf image changes colour on inclusion
by pdftex-bugs＠sarovar.org 14 Feb '11

14 Feb '11

Bugs item #4326, was opened at 2011-01-28 12:27 Status: Open Priority: 3 Submitted By: Matthis Thorade (thorade) Assigned to: Nobody (None) Summary: pdf image changes colour on inclusion Category: PDF inclusion Group: v1.40.8 Resolution: None Initial Comment: Hi, my problem is more or less identical to #741 (filed in 2007) but the problem persists in 2011, at least for me. As almost four years have passed since and all programs involved are now available as newer versions, I filed a new issue. Steps to reproduce: - Create input.svg with Inkscape 0.48 - Create input.pdf with "inkscape.exe --file="input.svg" --export-area-drawing --export-dpi=360 --export-pdf="input.pdf" " - Include input.pdf into some LaTeX document - Compile using pdflatex 1.40.11 from stable MiKTeX 2.9 on Win7 64bit - Open output.pdf and input.pdf with Adobe Reader X - Color in output.pdf is darker and less bright I searched google and found some (maybe) related posts: http://www.mrunix.de/forums/showthread.php?t=62241 http://www.latex-community.org/forum/viewtopic.php?f=5&t=2429 http://texblog.net/latex-archive/graphics/adobe-reader-wrong-color/ One suggested solution was to use a different pdf-Viewer. Using gsview or Evince the colors in output.pdf look fine; but if input.pdf and output.pdf look different in Adobe Reader X, then the only explanation I see is that pdfTeX changed something !? (And I won't try to persuade my Prof to use GSview...) Antoher suggested soultion (at least for png files) was to change the color mode from RGB to an indexed palette, but I have not yet tried this. ---------------------------------------------------------------------- Comment By: Matthis Thorade (thorade) Date: 2011-02-14 07:10 Message: Ok, thank you ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2011-02-14 01:02 Message: I confirm this is a bug introduced in 1.40.11 (1.40.10 was ok). This will be fixed soon. ---------------------------------------------------------------------- Comment By: Matthis Thorade (thorade) Date: 2011-02-10 11:02 Message: OK, as stated in ticket #741 this is due to some ColorSpace problems. The color space of pdfs can be checked with Acrobat Pro or for free at http://www.pdfcity.com/ Inkscape exports colors as RGB, even if they are specified in CMYK. Inkscape uses Cairo for exporting to pdf. Read more here: https://bugs.launchpad.net/inkscape/+bug/574717 pdfTeX outputs CMYK pdfs per default (at least this is what I assume, I tried a simple example containing only text and some colored text like hyperlinks created with hyperref package). Now when there is an RGB image included into the LaTeX document, the whole page where the image appears in the output pdf turns into RGB and all images, hyperlinks and references on this page slightly shift their color. In ticket #741 it was stated that a solution would be included in pdfTeX 1.40.6 or newer, but not how the solution would be implemented (or maybe I just did not understand it?), but the problem persists in pdfTeX 1.40.11. So even as the pdfTeX behavior should be changed here (in my opinion), the cleanest solution would be to include images in CMYK only (as the output pdf probably will be printed). As Inkscape does not support CMYK for pdf export yet, I will switch to some other vector drawing tool like Scribus, Illustrator or Corel Draw until CMYK export is available in Inkscape, too. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4326&group_id=106

1 0

[pdftex-Bugs][4326] pdf image changes colour on inclusion
by pdftex-bugs＠sarovar.org 14 Feb '11

14 Feb '11

Bugs item #4326, was opened at 2011-01-28 12:27 Status: Open Priority: 3 Submitted By: Matthis Thorade (thorade) Assigned to: Nobody (None) Summary: pdf image changes colour on inclusion Category: PDF inclusion Group: v1.40.8 Resolution: None Initial Comment: Hi, my problem is more or less identical to #741 (filed in 2007) but the problem persists in 2011, at least for me. As almost four years have passed since and all programs involved are now available as newer versions, I filed a new issue. Steps to reproduce: - Create input.svg with Inkscape 0.48 - Create input.pdf with "inkscape.exe --file="input.svg" --export-area-drawing --export-dpi=360 --export-pdf="input.pdf" " - Include input.pdf into some LaTeX document - Compile using pdflatex 1.40.11 from stable MiKTeX 2.9 on Win7 64bit - Open output.pdf and input.pdf with Adobe Reader X - Color in output.pdf is darker and less bright I searched google and found some (maybe) related posts: http://www.mrunix.de/forums/showthread.php?t=62241 http://www.latex-community.org/forum/viewtopic.php?f=5&t=2429 http://texblog.net/latex-archive/graphics/adobe-reader-wrong-color/ One suggested solution was to use a different pdf-Viewer. Using gsview or Evince the colors in output.pdf look fine; but if input.pdf and output.pdf look different in Adobe Reader X, then the only explanation I see is that pdfTeX changed something !? (And I won't try to persuade my Prof to use GSview...) Antoher suggested soultion (at least for png files) was to change the color mode from RGB to an indexed palette, but I have not yet tried this. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2011-02-14 01:02 Message: I confirm this is a bug introduced in 1.40.11 (1.40.10 was ok). This will be fixed soon. ---------------------------------------------------------------------- Comment By: Matthis Thorade (thorade) Date: 2011-02-10 11:02 Message: OK, as stated in ticket #741 this is due to some ColorSpace problems. The color space of pdfs can be checked with Acrobat Pro or for free at http://www.pdfcity.com/ Inkscape exports colors as RGB, even if they are specified in CMYK. Inkscape uses Cairo for exporting to pdf. Read more here: https://bugs.launchpad.net/inkscape/+bug/574717 pdfTeX outputs CMYK pdfs per default (at least this is what I assume, I tried a simple example containing only text and some colored text like hyperlinks created with hyperref package). Now when there is an RGB image included into the LaTeX document, the whole page where the image appears in the output pdf turns into RGB and all images, hyperlinks and references on this page slightly shift their color. In ticket #741 it was stated that a solution would be included in pdfTeX 1.40.6 or newer, but not how the solution would be implemented (or maybe I just did not understand it?), but the problem persists in pdfTeX 1.40.11. So even as the pdfTeX behavior should be changed here (in my opinion), the cleanest solution would be to include images in CMYK only (as the output pdf probably will be printed). As Inkscape does not support CMYK for pdf export yet, I will switch to some other vector drawing tool like Scribus, Illustrator or Corel Draw until CMYK export is available in Inkscape, too. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4326&group_id=106

1 0

[pdftex-Bugs][4326] pdf image changes colour on inclusion
by pdftex-bugs＠sarovar.org 10 Feb '11

10 Feb '11

Bugs item #4326, was opened at 2011-01-28 12:27 Status: Open Priority: 3 Submitted By: Matthis Thorade (thorade) Assigned to: Nobody (None) Summary: pdf image changes colour on inclusion Category: PDF inclusion Group: v1.40.8 Resolution: None Initial Comment: Hi, my problem is more or less identical to #741 (filed in 2007) but the problem persists in 2011, at least for me. As almost four years have passed since and all programs involved are now available as newer versions, I filed a new issue. Steps to reproduce: - Create input.svg with Inkscape 0.48 - Create input.pdf with "inkscape.exe --file="input.svg" --export-area-drawing --export-dpi=360 --export-pdf="input.pdf" " - Include input.pdf into some LaTeX document - Compile using pdflatex 1.40.11 from stable MiKTeX 2.9 on Win7 64bit - Open output.pdf and input.pdf with Adobe Reader X - Color in output.pdf is darker and less bright I searched google and found some (maybe) related posts: http://www.mrunix.de/forums/showthread.php?t=62241 http://www.latex-community.org/forum/viewtopic.php?f=5&t=2429 http://texblog.net/latex-archive/graphics/adobe-reader-wrong-color/ One suggested solution was to use a different pdf-Viewer. Using gsview or Evince the colors in output.pdf look fine; but if input.pdf and output.pdf look different in Adobe Reader X, then the only explanation I see is that pdfTeX changed something !? (And I won't try to persuade my Prof to use GSview...) Antoher suggested soultion (at least for png files) was to change the color mode from RGB to an indexed palette, but I have not yet tried this. ---------------------------------------------------------------------- Comment By: Matthis Thorade (thorade) Date: 2011-02-10 11:02 Message: OK, as stated in ticket #741 this is due to some ColorSpace problems. The color space of pdfs can be checked with Acrobat Pro or for free at http://www.pdfcity.com/ Inkscape exports colors as RGB, even if they are specified in CMYK. Inkscape uses Cairo for exporting to pdf. Read more here: https://bugs.launchpad.net/inkscape/+bug/574717 pdfTeX outputs CMYK pdfs per default (at least this is what I assume, I tried a simple example containing only text and some colored text like hyperlinks created with hyperref package). Now when there is an RGB image included into the LaTeX document, the whole page where the image appears in the output pdf turns into RGB and all images, hyperlinks and references on this page slightly shift their color. In ticket #741 it was stated that a solution would be included in pdfTeX 1.40.6 or newer, but not how the solution would be implemented (or maybe I just did not understand it?), but the problem persists in pdfTeX 1.40.11. So even as the pdfTeX behavior should be changed here (in my opinion), the cleanest solution would be to include images in CMYK only (as the output pdf probably will be printed). As Inkscape does not support CMYK for pdf export yet, I will switch to some other vector drawing tool like Scribus, Illustrator or Corel Draw until CMYK export is available in Inkscape, too. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4326&group_id=106

1 0

[pdftex-Bugs][4326] pdf image changes colour on inclusion
by pdftex-bugs＠sarovar.org 28 Jan '11

28 Jan '11

Bugs item #4326, was opened at 2011-01-28 12:27 Status: Open Priority: 3 Submitted By: Matthis Thorade (thorade) Assigned to: Nobody (None) Summary: pdf image changes colour on inclusion Category: PDF inclusion Group: v1.40.8 Resolution: None Initial Comment: Hi, my problem is more or less identical to #741 (filed in 2007) but the problem persists in 2011, at least for me. As almost four years have passed since and all programs involved are now available as newer versions, I filed a new issue. Steps to reproduce: - Create input.svg with Inkscape 0.48 - Create input.pdf with "inkscape.exe --file="input.svg" --export-area-drawing --export-dpi=360 --export-pdf="input.pdf" " - Include input.pdf into some LaTeX document - Compile using pdflatex 1.40.11 from stable MiKTeX 2.9 on Win7 64bit - Open output.pdf and input.pdf with Adobe Reader X - Color in output.pdf is darker and less bright I searched google and found some (maybe) related posts: http://www.mrunix.de/forums/showthread.php?t=62241 http://www.latex-community.org/forum/viewtopic.php?f=5&t=2429 http://texblog.net/latex-archive/graphics/adobe-reader-wrong-color/ One suggested solution was to use a different pdf-Viewer. Using gsview or Evince the colors in output.pdf look fine; but if input.pdf and output.pdf look different in Adobe Reader X, then the only explanation I see is that pdfTeX changed something !? (And I won't try to persuade my Prof to use GSview...) Antoher suggested soultion (at least for png files) was to change the color mode from RGB to an indexed palette, but I have not yet tried this. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4326&group_id=106

1 0

Re: [NTG-pdftex] [pdftex] Why does pdflatex needs pictures?
by Martin Schröder 13 Jan '11

13 Jan '11

2011/1/13 David Carlisle <davidc(a)nag.co.uk>: > It was always there, since the first test releases of graphics. Then why does grfguide say it's a new feature from 2006/06/20? :-) Best Martin

1 0

Re: [NTG-pdftex] [pdftex] Why does pdflatex needs pictures?
by Martin Schröder 13 Jan '11

13 Jan '11

2011/1/13 Lars Madsen <daleif(a)imf.au.dk>: > Martin Schröder wrote: >> \usepackage[demo]{graphicx}[2009/02/05] >> >> Or when was that added? :-) > > don't know, but if people do not have it, it is a good indication to update Sure, bot nobody expects new features (newer then TLC2) from the LaTeX core packages. :-) Especially if they are not mentioned in the LaTeX news. Best Martin

1 0

[pdftex-Bugs][4325] Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11)
by pdftex-bugs＠sarovar.org 12 Jan '11

12 Jan '11

Bugs item #4325, was opened at 2011-01-10 00:45 Status: Closed Priority: 3 Submitted By: Maverick Woo (maverickwoo) Assigned to: Nobody (None) Summary: Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11) Category: synctex Group: None Resolution: Invalid Initial Comment: I am using MiKTeX-pdfTeX 2.9.3962 (1.40.11). On one of my larger documents, it generates a synctex file in which the "Input:" lines are spread across the file, i.e., the "Input:" lines do not form a contiguous block at the beginning of the synctex file before the "Content:" line. This breaks the synctex parser in both SumatraPDF and TeXworks. Currently I use latexmk to fix the synctex file automatically after each build. The only thing needed is to move all the "Input:" lines to the front. ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-11 22:26 Message: Oops, in the process of trying to see if I can fix the code myself I realize I misread the code's comment about input records in _synctex_scan_preamble. Now I see that the current parser already expects "Input:" lines between sheets and that means the v1 spec already allows this. In other words I shouldn't have thought that this is a pdftex problem. Sorry. (Just want to set the record straight here and say sorry.) ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-11 00:59 Message: I see. I was under the impression that anything that can't be parsed by Jerome's C library is outside of the synctex version 1 specification. In particular, the _synctex_scan_preamble function seems to suggest that all "Input:" lines should appear between "SyncTeX Version:" and "Output:". That was why I decided to file the bug here. Thanks for the clarification. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2011-01-11 00:29 Message: This is not a pdftex problem, this is a synctex problem. The parser breaks in that situation. As the synctex parser code is shared by both sumatrapdf and texworks, both will fail in synchronizing. This will be fixed in next version of the synctex library. ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-10 20:50 Message: Attached is a minimal example that yields a synctex file with an "Input:" line after the "Content:" line. I compiled it with: pdflatex -synctex=1 main ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2011-01-10 18:09 Message: please provide a test file to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4325&group_id=106

1 0

[pdftex-Bugs][4325] Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11)
by pdftex-bugs＠sarovar.org 11 Jan '11

11 Jan '11

Bugs item #4325, was opened at 2011-01-10 06:45 >Status: Closed Priority: 3 Submitted By: Maverick Woo (maverickwoo) Assigned to: Nobody (None) Summary: Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11) Category: synctex Group: None >Resolution: Invalid Initial Comment: I am using MiKTeX-pdfTeX 2.9.3962 (1.40.11). On one of my larger documents, it generates a synctex file in which the "Input:" lines are spread across the file, i.e., the "Input:" lines do not form a contiguous block at the beginning of the synctex file before the "Content:" line. This breaks the synctex parser in both SumatraPDF and TeXworks. Currently I use latexmk to fix the synctex file automatically after each build. The only thing needed is to move all the "Input:" lines to the front. ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-11 06:59 Message: I see. I was under the impression that anything that can't be parsed by Jerome's C library is outside of the synctex version 1 specification. In particular, the _synctex_scan_preamble function seems to suggest that all "Input:" lines should appear between "SyncTeX Version:" and "Output:". That was why I decided to file the bug here. Thanks for the clarification. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2011-01-11 06:29 Message: This is not a pdftex problem, this is a synctex problem. The parser breaks in that situation. As the synctex parser code is shared by both sumatrapdf and texworks, both will fail in synchronizing. This will be fixed in next version of the synctex library. ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-11 02:50 Message: Attached is a minimal example that yields a synctex file with an "Input:" line after the "Content:" line. I compiled it with: pdflatex -synctex=1 main ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2011-01-11 00:09 Message: please provide a test file to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4325&group_id=106

1 0

[pdftex-Bugs][4325] Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11)
by pdftex-bugs＠sarovar.org 11 Jan '11

11 Jan '11

Bugs item #4325, was opened at 2011-01-10 00:45 Status: Open Priority: 3 Submitted By: Maverick Woo (maverickwoo) Assigned to: Nobody (None) Summary: Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11) Category: synctex Group: None Resolution: None Initial Comment: I am using MiKTeX-pdfTeX 2.9.3962 (1.40.11). On one of my larger documents, it generates a synctex file in which the "Input:" lines are spread across the file, i.e., the "Input:" lines do not form a contiguous block at the beginning of the synctex file before the "Content:" line. This breaks the synctex parser in both SumatraPDF and TeXworks. Currently I use latexmk to fix the synctex file automatically after each build. The only thing needed is to move all the "Input:" lines to the front. ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-11 00:59 Message: I see. I was under the impression that anything that can't be parsed by Jerome's C library is outside of the synctex version 1 specification. In particular, the _synctex_scan_preamble function seems to suggest that all "Input:" lines should appear between "SyncTeX Version:" and "Output:". That was why I decided to file the bug here. Thanks for the clarification. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2011-01-11 00:29 Message: This is not a pdftex problem, this is a synctex problem. The parser breaks in that situation. As the synctex parser code is shared by both sumatrapdf and texworks, both will fail in synchronizing. This will be fixed in next version of the synctex library. ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-10 20:50 Message: Attached is a minimal example that yields a synctex file with an "Input:" line after the "Content:" line. I compiled it with: pdflatex -synctex=1 main ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2011-01-10 18:09 Message: please provide a test file to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4325&group_id=106

1 0

[pdftex-Bugs][4325] Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11)
by pdftex-bugs＠sarovar.org 11 Jan '11

11 Jan '11

Bugs item #4325, was opened at 2011-01-10 07:45 Status: Open Priority: 3 Submitted By: Maverick Woo (maverickwoo) Assigned to: Nobody (None) Summary: Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11) Category: synctex Group: None Resolution: None Initial Comment: I am using MiKTeX-pdfTeX 2.9.3962 (1.40.11). On one of my larger documents, it generates a synctex file in which the "Input:" lines are spread across the file, i.e., the "Input:" lines do not form a contiguous block at the beginning of the synctex file before the "Content:" line. This breaks the synctex parser in both SumatraPDF and TeXworks. Currently I use latexmk to fix the synctex file automatically after each build. The only thing needed is to move all the "Input:" lines to the front. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2011-01-11 07:29 Message: This is not a pdftex problem, this is a synctex problem. The parser breaks in that situation. As the synctex parser code is shared by both sumatrapdf and texworks, both will fail in synchronizing. This will be fixed in next version of the synctex library. ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-11 03:50 Message: Attached is a minimal example that yields a synctex file with an "Input:" line after the "Content:" line. I compiled it with: pdflatex -synctex=1 main ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2011-01-11 01:09 Message: please provide a test file to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4325&group_id=106

1 0

[pdftex-Bugs][4325] Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11)
by pdftex-bugs＠sarovar.org 11 Jan '11

11 Jan '11

Bugs item #4325, was opened at 2011-01-10 00:45 Status: Open Priority: 3 Submitted By: Maverick Woo (maverickwoo) Assigned to: Nobody (None) Summary: Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11) Category: synctex Group: None Resolution: None Initial Comment: I am using MiKTeX-pdfTeX 2.9.3962 (1.40.11). On one of my larger documents, it generates a synctex file in which the "Input:" lines are spread across the file, i.e., the "Input:" lines do not form a contiguous block at the beginning of the synctex file before the "Content:" line. This breaks the synctex parser in both SumatraPDF and TeXworks. Currently I use latexmk to fix the synctex file automatically after each build. The only thing needed is to move all the "Input:" lines to the front. ---------------------------------------------------------------------- Comment By: Maverick Woo (maverickwoo) Date: 2011-01-10 20:50 Message: Attached is a minimal example that yields a synctex file with an "Input:" line after the "Content:" line. I compiled it with: pdflatex -synctex=1 main ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2011-01-10 18:09 Message: please provide a test file to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4325&group_id=106

1 0

[pdftex-Bugs][4325] Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11)
by pdftex-bugs＠sarovar.org 11 Jan '11

11 Jan '11

Bugs item #4325, was opened at 2011-01-10 06:45 Status: Open Priority: 3 Submitted By: Maverick Woo (maverickwoo) Assigned to: Nobody (None) Summary: Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11) Category: synctex Group: None Resolution: None Initial Comment: I am using MiKTeX-pdfTeX 2.9.3962 (1.40.11). On one of my larger documents, it generates a synctex file in which the "Input:" lines are spread across the file, i.e., the "Input:" lines do not form a contiguous block at the beginning of the synctex file before the "Content:" line. This breaks the synctex parser in both SumatraPDF and TeXworks. Currently I use latexmk to fix the synctex file automatically after each build. The only thing needed is to move all the "Input:" lines to the front. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2011-01-11 00:09 Message: please provide a test file to reproduce the problem. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4325&group_id=106

1 0

[pdftex-Bugs][4325] Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11)
by pdftex-bugs＠sarovar.org 10 Jan '11

10 Jan '11

Bugs item #4325, was opened at 2011-01-10 00:45 Status: Open Priority: 3 Submitted By: Maverick Woo (maverickwoo) Assigned to: Nobody (None) Summary: Input lines spread across synctex file in MiKTeX-pdfTeX 2.9.3962 (1.40.11) Category: synctex Group: None Resolution: None Initial Comment: I am using MiKTeX-pdfTeX 2.9.3962 (1.40.11). On one of my larger documents, it generates a synctex file in which the "Input:" lines are spread across the file, i.e., the "Input:" lines do not form a contiguous block at the beginning of the synctex file before the "Content:" line. This breaks the synctex parser in both SumatraPDF and TeXworks. Currently I use latexmk to fix the synctex file automatically after each build. The only thing needed is to move all the "Input:" lines to the front. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=4325&group_id=106

1 0

\pdfximage : is there a transparency attribute or method ?
by Philip Taylor (Webmaster, Ret'd) 07 Jan '11

07 Jan '11

I am attempting to incorporate http://thai-an.co.uk/Resources/Graphics/thai-an-logo-no-phone.png as a background image in PdfTeX, and of course it is far too saturated to use as-is. While I could manipulate it in Photoshop or similar, I wonder if there is a more direct way whereby I can specify (say) its transparency in PdfTeX so as to effectively reduce its saturation ? Philip Taylor -- Not sent from my i-Pad, i-Phone, Blackberry, Blueberry, or any such similar poseurs' toy, none of which would I be seen dead with even if they came free with every packet of cornflakes.

6 13