- ntg-pdftex - NTG Mailing Lists

[pdftex] New document - KXUJydKuCBJI
by noreply＠sarovar.org 14 Jun '08

14 Jun '08

Project: pdftex Group: Document title: KXUJydKuCBJI Document description: gtaMXjBRczHnHf Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

pdf/a-1b preflight warning: glyph width info incomplete/inconsistent
by The Thanh Han 09 Jun '08

09 Jun '08

Hi, I encountered an interesting problem with pdf/a-1b checking: if a pdf (produced by pdftex) contains a glyph with zero width (for example, /mapsto from blsy/mtsy), then pdf/a-1b preflight by Acrobat8 gives warnings about incomplete/inconsistent width info. From the technical view, the pdf file seems to be ok: the glyph width in the fontinfo dict is 0 (read from mtsy.tfm), and from the font program: ,-------- | /mapsto { | 56 0 hsbw | ... `-------- So the reason seems that when Acrobat sees a zero glyph width, it treates that width as "missing". Does anyone have some similar experience with this? Thanh

2 1

[pdftex-Bugs][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-bugs＠sarovar.org 07 Jun '08

07 Jun '08

Bugs item #1242, was opened at 2008-06-06 14:53 >Status: Open Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access Resolution: Invalid Group: None Category: None Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- >Comment By: Taco Hoekwater (taco) Date: 2008-06-07 09:39 Message: I can see this is can easily be a problem everywhere, especially in networked environments, so will reopen the report, but file locking is probably not the best way to fix the symptoms. Locking files (and detecting locks) on a local harddisk is already quite hard to implement in a portable manner, never mind attempting todo the same over a network share. So if you really want file locking, you probably should talk to the miktex maintainer, as that is not likely to make it into pdftex (or luatex)'s core distribution. However, it would be pretty easy to make pdftex create a PDF file with a temporary name and rename it only at the end of a succesful run. As a side bonus, that would also prevent the existance of partial == broken pdfs. I believe that is something to consider for 1.50 or luatex. ---------------------------------------------------------------------- Comment By: William Blum (wblum) Date: 2008-06-06 23:20 Message: > We don't support MikTeX-pdfTeX; please discuss this with the > MikTeX maintainer. This bug does not affect only MikTex! I have just tried with teTeX on cygwin and the same problem occurs. I suspect that all TeX distributions suffer from the same bug since there is no reason for them to change the way the files are opened by pdftex. Since all distributions derive from the pdftex code maintained here, I though it would make more sense to patch the bug at the source... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-06 15:45 Message: We don't support MikTeX-pdfTeX; please discuss this with the MikTeX maintainer. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1242&group_id=106

1 0

[pdftex-Bugs][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-bugs＠sarovar.org 06 Jun '08

06 Jun '08

Bugs item #1242, was opened at 2008-06-06 13:53 Status: Closed Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access Resolution: Invalid Group: None Category: None Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- Comment By: William Blum (wblum) Date: 2008-06-06 22:20 Message: > We don't support MikTeX-pdfTeX; please discuss this with the > MikTeX maintainer. This bug does not affect only MikTex! I have just tried with teTeX on cygwin and the same problem occurs. I suspect that all TeX distributions suffer from the same bug since there is no reason for them to change the way the files are opened by pdftex. Since all distributions derive from the pdftex code maintained here, I though it would make more sense to patch the bug at the source... ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-06-06 14:45 Message: We don't support MikTeX-pdfTeX; please discuss this with the MikTeX maintainer. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1242&group_id=106

1 0

[pdftex-Bugs][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-bugs＠sarovar.org 06 Jun '08

06 Jun '08

Bugs item #1242, was opened at 2008-06-06 14:53 >Status: Closed Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access >Resolution: Invalid Group: None Category: None Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2008-06-06 15:45 Message: We don't support MikTeX-pdfTeX; please discuss this with the MikTeX maintainer. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1242&group_id=106

1 0

[pdftex-Bugs][1242] pdftex opens the .pdf output file with write sharing access
by pdftex-bugs＠sarovar.org 06 Jun '08

06 Jun '08

Bugs item #1242, was opened at 2008-06-06 13:53 Status: Open Priority: 3 Submitted By: William Blum (wblum) Assigned to: Nobody (None) Summary: pdftex opens the .pdf output file with write sharing access Resolution: None Group: None Category: None Initial Comment: pdftex v1.40.7 opens the output .pdf file with write sharing access (at least on the Miktex distribution). This is bad for many reasons (and can actually be an indirect cause of file locking problems in some situations). This means that you can start two instances of pdftex on the same .tex file without getting any error, the writing operations gets interleaved and you end up with a corrupt .pdf. pdftex should open the file with read sharing access only. If the file is opened using the C++ fstream::open function then this means setting the protection mode to 'filebuf::sh_read' but not to 'filebuf::sh_write'. That way if another instance is running, it will prevent the new instance from writing into the file. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1242&group_id=106

1 0

Announcement: changes and plan for pdftex
by The Thanh Han 05 Jun '08

05 Jun '08

Announcement: changes and plan for pdftex Dear all, in the context of the forthcoming luatex (which is supposed to be pdftex successor), the pdftex team has agreed on the following decisions: - we plan to release 1.40.8 soon, which will be included in texlive2008. The next version will be 1.50.0 and after that version, pdftex development will be essentially stopped. From 1.50.0 onwards, in principle only bug fixes are accepted. - from now on, pdftex will be maintained by me (Han The Thanh). I and all other members of the pdftex team thank Martin Schr\"oder for his great effort on pdftex maintainance over the years. Thanks to him we've seen a steady stream of pdftex releases. - more structural development takes place in the luatex project, which is a continuation of pdftex. However, we will still do our best to keep pdftex stable and compliant to pdf standards. In this respect, after 1.50.0 we might have to accept some extensions (most likely backported from luatex) that are required to keep pdftex compliant with new pdf standards, but only in case it is unavoidable. on the behalf of the pdftex team, Han The Thanh

1 0

! TeX capacity exceeded, sorry [parameter stack size=6000].
by Vit Zyka 03 Jun '08

03 Jun '08

Hi pdftex team, I have encountered the problem with the stack_size parameter. Enlarging a complex context document results in the error ! TeX capacity exceeded, sorry [parameter stack size=6000]. Since a compilation of individual document parts is OK I do not believe in the recurse problem. Interesting is that texmf.cnf sets (TL 07): stack_size = 5000 stack_size.context = 10000 so I was curious why pdftex (tested on 1.40.5 and the current 1.40.8) is writting about 6000. It seems to me it simply cuts down the number greater then 6000. - Is the 6000 a real limit? - If so then context setting to 10000 is useless. - If not can it be increased a bit? Let us say to 10000? Thanks Vit Zyka

3 2

Re: [NTG-pdftex] Bug#458059:
by Frank Küster 01 Jun '08

01 Jun '08

Dear TeX(-k) people, dear pdfTeX team, late last year Norbert Preining already asked on the TeXk list about a problem encountered in Debian, namely a TeX capacity exceeded error on grouping levels. Nobody could help back then, but now someone started to analyse this further (many thanks, Stijn!). So could you please (again) have a look? It seems the value is hardcoded in the sources, "Stijn van Drongelen" <tinctorius(a)gmail.com> wrote: > The issue seems to have its roots in build/source/texk/web2c/tex.web, > line 5925-5930: > > if cur_level=max_quarterword then overflow("grouping levels", > @:TeX capacity exceeded grouping levels}{\quad grouping levels@> > max_quarterword-min_quarterword); > {quit if |(cur_level+1)| is too big to be stored in |eqtb|} > cur_boundary:=save_ptr; incr(cur_level); incr(save_ptr); cur_group:=c; > end; > > So if 'cur_level' exceeds the maximum quarterword size, TeX dies. > These constants are defined in 2411-2414: > > @d min_quarterword=0 {smallest allowable value in a |quarterword|} > @d max_quarterword=255 {largest allowable value in a |quarterword|} > @d min_halfword==0 {smallest allowable value in a |halfword|} > @d max_halfword==65535 {largest allowable value in a |halfword|} > > And on line 2409, it says: "The values defined here are recommended > for most 32-bit computers." > > I use amd64. I can deal with max_quarterword=65535 etc. > > Why aren't these quarterword/halfword bounds configurable? There is a configuration variable nest_size level, but it doesn't seem to help in this case: The attached file gives an error ! TeX capacity exceeded, sorry [grouping levels=255]. although my texmf.cnf has nest_size=500. Should/can we change max_quarterword, or are there side effects? Or should the grouping levels instead use halfword? Or would you like to do it in a completely different way? This is a real life problem which affects building the PostgreSQL documentatin. Many thanks in advance, Frank -- Frank Küster Debian Developer (teTeX/TeXLive)

6 11

Re: [NTG-pdftex] [pdftex-Bugs][1042] v1.50 pdf figure
by Akira Kakuto 30 May '08

30 May '08

> I'll investigate and will fix the problem in > 1.40.8-beta ASAP. The corrected tar ball of 1.40.8-beta (win32) will be available after 22:00, May 30 (JST). Best regards, Akira

1 0

Re: [NTG-pdftex] [pdftex-Bugs][1042] v1.50 pdf figure
by Akira Kakuto 29 May '08

29 May '08

> When I use pdflatex (pdfTeX 3.1415926-1.50.0-alpha-20080414-2.2 (Web2C 7.5.6)) > to include pdf figures, I found that all pdf figures cannot be included! This is a WIN32-only problem (also in 1.40.8-beta). I'll investigate and will fix the problem in 1.40.8-beta ASAP. Best regards, Akira

1 0

[pdftex-Bugs][1042] v1.50 pdf figure inclusion failure
by pdftex-bugs＠sarovar.org 29 May '08

29 May '08

Bugs item #1042, was opened at 2008-05-29 10:41 Status: Open Priority: 3 Submitted By: Hongbin Ma (mathmhb) Assigned to: Nobody (None) Summary: v1.50 pdf figure inclusion failure Resolution: None Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: When I use pdflatex (pdfTeX 3.1415926-1.50.0-alpha-20080414-2.2 (Web2C 7.5.6)) to include pdf figures, I found that all pdf figures cannot be included! ----Cut from log file--- !pdfTeX error: pdftex.exe (file ./fig-test.pdf): xpdf: reading PDF image failed (0) ==> Fatal error occurred, no output PDF file produced! ------------------------ This is a serious problem because the pdf inclusion can work well with the stable version pdftex 1.40.7. See attached file for a test tex file and the details of log file. In this example, a pdf figure is inserted by \includegraphics command. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=1042&group_id=106

1 0

[pdftex] New document - vQKwlEroqOrISpOxR
by noreply＠sarovar.org 27 May '08

27 May '08

Project: pdftex Group: Document title: vQKwlEroqOrISpOxR Document description: fvxwUcRPhmHR Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

2 2

[pdftex] New document - foofoo
by noreply＠sarovar.org 27 May '08

27 May '08

Project: pdftex Group: Document title: foofoo Document description: 1234567890 Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

[pdftex] New document - vQKwlEroqOrISpOxR
by noreply＠sarovar.org 27 May '08

27 May '08

Project: pdftex Group: Document title: vQKwlEroqOrISpOxR Document description: fvxwUcRPhmHR Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

[pdftex] New document - vQKwlEroqOrISpOxR
by noreply＠sarovar.org 27 May '08

27 May '08

Project: pdftex Group: Document title: vQKwlEroqOrISpOxR Document description: fvxwUcRPhmHR Submitter: Nobody (None) ------------------------------------------------------- For more info, visit: http://sarovar.org/docman/index.php?group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 27 May '08

27 May '08

Bugs item #993, was opened at 2008-05-24 13:24 Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly Resolution: None Group: v1.40.6 Category: None Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 16:48 Message: ok then this should be fixed as the spec says. BTW, it doesn't really solve the reported problem (ü will come after eg z). ---------------------------------------------------------------------- Comment By: Hans Hagen (hagen) Date: 2008-05-27 16:03 Message: the spec says: The Names entries in the leaf (or root) nodes contain the tree’s keys and their associated values, arranged in key-value pairs and sorted lexically in ascending order by key. Shorter keys appear before longer ones beginning with the same byte sequence. The encoding of the keys is immaterial as long as it is self-consistent; keys are compared for equality on a simple byte-by-byte basis. so, it's just bytes ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 15:43 Message: this is a problem, but it's not clear to me how it should be fixed. Assume that we translate "\374" to the corresponding charcode (0374 = 252) before sorting, then how we decide the lexicographic order of that char? it can be intepreted as ü but also can be eg ytilde or something different, depending on the encoding we use. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 27 May '08

27 May '08

Bugs item #993, was opened at 2008-05-24 13:24 Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly Resolution: None Group: v1.40.6 Category: None Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- >Comment By: Hans Hagen (hagen) Date: 2008-05-27 16:03 Message: the spec says: The Names entries in the leaf (or root) nodes contain the tree’s keys and their associated values, arranged in key-value pairs and sorted lexically in ascending order by key. Shorter keys appear before longer ones beginning with the same byte sequence. The encoding of the keys is immaterial as long as it is self-consistent; keys are compared for equality on a simple byte-by-byte basis. so, it's just bytes ---------------------------------------------------------------------- Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 15:43 Message: this is a problem, but it's not clear to me how it should be fixed. Assume that we translate "\374" to the corresponding charcode (0374 = 252) before sorting, then how we decide the lexicographic order of that char? it can be intepreted as ü but also can be eg ytilde or something different, depending on the encoding we use. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 27 May '08

27 May '08

Bugs item #993, was opened at 2008-05-24 13:24 Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly Resolution: None Group: v1.40.6 Category: None Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- >Comment By: The Thanh Han (hanthethanh) Date: 2008-05-27 15:43 Message: this is a problem, but it's not clear to me how it should be fixed. Assume that we translate "\374" to the corresponding charcode (0374 = 252) before sorting, then how we decide the lexicographic order of that char? it can be intepreted as ü but also can be eg ytilde or something different, depending on the encoding we use. Comments? ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0

[pdftex-Bugs][993] /Names array not sorted correctly
by pdftex-bugs＠sarovar.org 24 May '08

24 May '08

Bugs item #993, was opened at 2008-05-24 15:24 Status: Open Priority: 3 Submitted By: Martin Schröder (oneiros) Assigned to: The Thanh Han (hanthethanh) Summary: /Names array not sorted correctly Resolution: None Group: v1.40.6 Category: None Initial Comment: Axel Berger and Heiko Oberdiek report an error with the sorting of the /Names array: /Names [(cite.Kr07) 44 0 R (cite.Li08) 45 0 R (cite.M\37403) 23 0 R (cite.Mi00) 47 0 R (cite.Mi84) 48 0 R (cite.Mo04) 50 0 R] "cite.Mü03" (= "cite.M\37403") should come after "cite.Mo04". A test file with output is attached. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=993&group_id=106

1 0

[pdftex-Patches][962] SyncTeX
by pdftex-patches＠sarovar.org 22 May '08

22 May '08

Patches item #962, was opened at 2008-05-20 18:01 Status: Open Priority: 3 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Nobody (None) Summary: SyncTeX Resolution: None Group: v1.50.0 Category: User interaction Initial Comment: Dear all, SyncTeX design has changed. In order to add support in pdftex for the new design, we must clean the previous code from everything containing SyncTeX. Enclosed is a diff file against URL: svn://scm.foundry.supelec.fr/svn/pdftex/trunk Revision: 470 Everything concerning the old synctex design has been removed. The next step will be to add support for the latest design. It will be quite straightforward once the texlive repository is up to date. ---------------------------------------------------------------------- Comment By: Jerome LAURENS (jlaurens) Date: 2008-05-22 21:45 Message: There was a mistake in the previous cleaning process that caused a segmentation fault. Curiously, it seemed to appear randomly. Anyway, with this patch, the diff between pdftex.web and the texlive version don't show anything related to synctex. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=962&group_id=106

1 0

[pdftex-Patches][962] SyncTeX
by pdftex-patches＠sarovar.org 20 May '08

20 May '08

Patches item #962, was opened at 2008-05-20 18:01 Status: Open Priority: 3 Submitted By: Jerome LAURENS (jlaurens) Assigned to: Nobody (None) Summary: SyncTeX Resolution: None Group: v1.50.0 Category: User interaction Initial Comment: Dear all, SyncTeX design has changed. In order to add support in pdftex for the new design, we must clean the previous code from everything containing SyncTeX. Enclosed is a diff file against URL: svn://scm.foundry.supelec.fr/svn/pdftex/trunk Revision: 470 Everything concerning the old synctex design has been removed. The next step will be to add support for the latest design. It will be quite straightforward once the texlive repository is up to date. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=495&aid=962&group_id=106

1 0

Help!!
by Paul Suen 09 May '08

09 May '08

Hello all, I'm a project manager just involving in a big project(About 0.5 million users). I just using pdftex tool to transfer TEX file to PDF. But the performance is not accepted, especially in IBM AIX operating system. In windows, the performance is about 1 second on file. But in AIX(4 CPU, 8G memory), it needs 20 seconds. Can anybody give me some advice about this problem. Now I face grate pressure from the customer. The customer need to process all 0.5 million files in one day. Thanks. Paul,

2 1

[pdftex-Bugs][941] pdf inclusion broken on ppc-linux
by pdftex-bugs＠sarovar.org 06 May '08

06 May '08

Bugs item #941, was opened at 2008-04-22 10:32 >Status: Closed Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: pdf inclusion broken on ppc-linux Resolution: Fixed Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: pdf inclusion is currently broken on ppc-linux (see http://www.ntg.nl/pipermail/ntg-pdftex/2008-April/003500.html ). ---------------------------------------------------------------------- Comment By: Martin Schröder (oneiros) Date: 2008-05-06 13:01 Message: Fixed in HEAD. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=941&group_id=106

1 0

[pdftex-Bugs][941] pdf inclusion broken on ppc-linux
by pdftex-bugs＠sarovar.org 06 May '08

06 May '08

Bugs item #941, was opened at 2008-04-22 10:32 Status: Open Priority: 5 Submitted By: Martin Schröder (oneiros) Assigned to: Martin Schröder (oneiros) Summary: pdf inclusion broken on ppc-linux >Resolution: Fixed Group: v1.50.0-alpha Category: PDF inclusion Initial Comment: pdf inclusion is currently broken on ppc-linux (see http://www.ntg.nl/pipermail/ntg-pdftex/2008-April/003500.html ). ---------------------------------------------------------------------- >Comment By: Martin Schröder (oneiros) Date: 2008-05-06 13:01 Message: Fixed in HEAD. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=941&group_id=106

1 0