From chiapas at gmail.com  Tue Jan 10 10:12:42 2012
From: chiapas at gmail.com (Yih-Dar Shieh)
Date: Tue, 10 Jan 2012 10:12:42 +0100
Subject: [pdftex] A naive idea about forward-inverse search (not synctex)
Message-ID: <CANcoHvfNztrPtHR1p1hR7PMU_VTUCmgaZe1fvm+i5mFBWAhhGw@mail.gmail.com>

I used synctex to get the forward-inverse search between tex source and pdf
file. It created a .synctex file which record the coordinate
correspondences between .tex and .pdf. I have the following naive idea:
during compilation, each time we get some "output", we put an "extra
information". This "extra information" should be contents of the output
pdf, which is invisible, and do not affect the layout (using this feature
or not).
For example, it is similar to "hypperef", which has an "extra information"
so we can go to another location on the .pdf. The "extra information" for
this forward-inverse search could be "(line,column)" of the .tex source.
The following example may make this clear:

Tex Source: .....This is an example.

And the output PDF: ...T(1,1)h(1,2)i(1,3)s(1,4) (1,5)i(1,6)s(1,7)
(1,8)a(1,9)n(1,10) (1,11)e(1,12)x(1,13)a(1,14)m(1,15)p(1,16)l(1,14)e(1,18).

The (x,y) should be invisible on PDF, and the location should be at the
same location of their corresponding "output letter" and the space it takes
is the size of a single letter. This means that:
(the above example): when we click "T", we get an information (1,1) , just
similar to hyperref. Similarly, when we click "h", we get (1,2). If this is
done, then it is easy to do the inverse search (from pdf to tex), since the
information is on the pdf file. For forward search, it is easy also: when
we click on tex source, of course the editor knows the (line,column), and
it sends this information to pdf viewer and finally the viewer "go to the
location of this (line, column)". (Suppose the viewer could "Find" where is
(line,column), this need to be implemented.)

Of course, the size of the output pdf with this sync option will be large.
But we can do this by using "word" instead of "letter" for text and using
"each symbol" for math formula.

The advantage of this feature (to synctex) is: We get  very precise
locations when we do forward-inverse search. And the implemention should
not be difficult, since it just do "something extra" which are easy: get
the (x,y) on the source--OK ; Produce invisible output--Don't know if this
is possible. Compare to synctex method, we don't have to calculate the
coordinate correspondence between source and output. Also, the time needed
to compile is (about) double at most.

The disadvantage is that the output pdf has large size. Of course, after we
finish the work of typping, and want to publish the .pdf file, we can
compile it without sync option.

Although I say this would be easy, I mean this would be easy for developers
of pdftex. The ability to do this is far beyond my programming ability. I
would like to know from you that if this naive idea is doable. If not, what
are the difficulities? Do you think this is a good idea? And of course, if
we agree this is a good idea, I hope the developers could implement it.

Best Regards,
Yih-Dar Shieh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/pdftex/attachments/20120110/ec50e0c1/attachment.html>

From pchauvat at laposte.net  Wed Jan 11 10:54:28 2012
From: pchauvat at laposte.net (Philippe Chauvat)
Date: Wed, 11 Jan 2012 09:54:28 +0000 (UTC)
Subject: [pdftex] PDF empty with Acrobat / xpdf
References: <4E087F98.8010801@laposte.net> <4E088D55.4020007@imf.au.dk>
 <4E089534.3030805@laposte.net> <201106271149.01929.john@wexfordpress.com>
 <BANLkTikAUYGJtoskCgENhApmEeEPdtg69w@mail.gmail.com>
Message-ID: <loom.20120111T104524-305@post.gmane.org>

Martin Schr?der <martin at ...> writes:

> 
> 2011/6/27 John Culleton <john at ...>:
> > First of all you did not use pdftex. You used some form of LaTeX. This is
> 
> Peace. The file is produced by pdf(la)tex.
Thanks Martin.
> 
> Best
>    Martin
> 
> 
For those who are interested in the solution I found thanks to the help provided
by you all, here it is:
I tried with something else than the original PDF included as background, and it
worked.
So I just redo the letterhead with Inkscape (SVG) and then produced a PDF.
Everything works fine now.
The original PDF was produced by Adobe Illustrator. As far as I am *not* an
Adobe Illustrator user, I can not answer to any 'why' or 'how' question.

What I can say is: Thank you all for your valuable help !

Philippe




From wl at gnu.org  Sun Jan 22 20:50:17 2012
From: wl at gnu.org (Werner LEMBERG)
Date: Sun, 22 Jan 2012 20:50:17 +0100 (CET)
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <20111229.082748.18292415.wl@gnu.org>
References: <20111229.082748.18292415.wl@gnu.org>
Message-ID: <20120122.205017.06687362.wl@gnu.org>


A month ago I wrote:

> I consider this a bug in pdftex.
> 
> While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is version
> 1.06 (file `c059013l.pfb' from ghostscript), pdftex uses
> `uncr8a.pfb' from TeXLive, which is version 1.05.  Obviously,
> version 1.05 misses all Cyrillic glyphs.  IMHO, the right solution
> is to allow font merging only if the font versions are identical.

Is someone going to fix this?


    Werner

From p.stephani2 at googlemail.com  Sun Jan 22 21:42:04 2012
From: p.stephani2 at googlemail.com (Philipp Stephani)
Date: Sun, 22 Jan 2012 21:42:04 +0100
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <20120122.205017.06687362.wl@gnu.org>
References: <20111229.082748.18292415.wl@gnu.org>
 <20120122.205017.06687362.wl@gnu.org>
Message-ID: <CAArVCkSsQYsDeeDyHneqbqCfjnKq7v10tCi92+skKsnQUDkyuA@mail.gmail.com>

2012/1/22 Werner LEMBERG <wl at gnu.org>:
>
> A month ago I wrote:
>
>> I consider this a bug in pdftex.
>>
>> While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is version
>> 1.06 (file `c059013l.pfb' from ghostscript), pdftex uses
>> `uncr8a.pfb' from TeXLive, which is version 1.05. ?Obviously,
>> version 1.05 misses all Cyrillic glyphs. ?IMHO, the right solution
>> is to allow font merging only if the font versions are identical.
>
> Is someone going to fix this?

Development for PDFTeX has essentially stopped, so I wouldn't hold my breath.


From wl at gnu.org  Mon Jan 23 08:31:30 2012
From: wl at gnu.org (Werner LEMBERG)
Date: Mon, 23 Jan 2012 08:31:30 +0100 (CET)
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <20252.34118.335900.699784@zaphod.ms25.net>
References: <20111229.082748.18292415.wl@gnu.org>
 <20120122.205017.06687362.wl@gnu.org>
 <20252.34118.335900.699784@zaphod.ms25.net>
Message-ID: <20120123.083130.222913262.wl@gnu.org>

>  > > While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is
>  > > version 1.06 (file `c059013l.pfb' from ghostscript), pdftex
>  > > uses `uncr8a.pfb' from TeXLive, which is version 1.05.
>  > > Obviously, version 1.05 misses all Cyrillic glyphs.  IMHO, the
>  > > right solution is to allow font merging only if the font
>  > > versions are identical.
>  > 
>  > Is someone going to fix this?
> 
> PdfTeX already merges fonts only if they have the same /FontName and
> /UniqueID.

But the concept of /UniqueID has been abandonded by Adobe a very long
time ago:

  http://typophile.com/node/18749

(This link is from 2006.)  So it's actually another bug if pdftex
relies on it.

> However, ghostschript provides fonts with are buggy in this respect.
> They contain additional glyphs but have the same /FontName and
> /UniqueID as the original URW fonts.  I don't know how pdfTeX should
> recognize this.

As I've already mentioned: Use the font's version (1.05 vs. 1.06 in
the example given by me)!  If someone produces fonts which are
different but have exactly the same identifier, nothing can be done
except punishing the font developer.


    Werner

From hanthethanh at gmail.com  Mon Jan 23 11:32:38 2012
From: hanthethanh at gmail.com (Thanh Han The)
Date: Mon, 23 Jan 2012 11:32:38 +0100
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <20120123.083130.222913262.wl@gnu.org>
References: <20111229.082748.18292415.wl@gnu.org>
 <20120122.205017.06687362.wl@gnu.org>
 <20252.34118.335900.699784@zaphod.ms25.net>
 <20120123.083130.222913262.wl@gnu.org>
Message-ID: <CAD5iDTC2PuLXVtRNDdbFC9bhqJkReC2uoOLgPj0Eyh++L2Jo5Q@mail.gmail.com>

On Mon, Jan 23, 2012 at 8:31 AM, Werner LEMBERG <wl at gnu.org> wrote:
>> ?> > While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is
>> ?> > version 1.06 (file `c059013l.pfb' from ghostscript), pdftex
>> ?> > uses `uncr8a.pfb' from TeXLive, which is version 1.05.
>> ?> > Obviously, version 1.05 misses all Cyrillic glyphs. ?IMHO, the
>> ?> > right solution is to allow font merging only if the font
>> ?> > versions are identical.
>> ?>
>> ?> Is someone going to fix this?
>>
>> PdfTeX already merges fonts only if they have the same /FontName and
>> /UniqueID.
>
> But the concept of /UniqueID has been abandonded by Adobe a very long
> time ago:
>
> ?http://typophile.com/node/18749
>
> (This link is from 2006.) ?So it's actually another bug if pdftex
> relies on it.
>
>> However, ghostschript provides fonts with are buggy in this respect.
>> They contain additional glyphs but have the same /FontName and
>> /UniqueID as the original URW fonts. ?I don't know how pdfTeX should
>> recognize this.
>
> As I've already mentioned: Use the font's version (1.05 vs. 1.06 in
> the example given by me)! ?If someone produces fonts which are
> different but have exactly the same identifier, nothing can be done
> except punishing the font developer.

pdftex considers two fonts are the same if they have the same
/FontName (/UniqueID is not used).

comparing font version is certain a better way to do it, but the
change is not something like a few lines of code. pdftex must parse
the font file (from disk) and the font embedded in the pdf. Both are
doable but not trivial due to the way pdftex handles fonts now.

In the meantime, perhaps setting \pdfinclusioncopyfonts=1 (as the
default value at engine level) is the safe thing to do (with the risk
that some people will blame pdftex for increasing pdf output size).

Thanh


From wl at gnu.org  Mon Jan 23 14:14:47 2012
From: wl at gnu.org (Werner LEMBERG)
Date: Mon, 23 Jan 2012 14:14:47 +0100 (CET)
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <CAD5iDTC2PuLXVtRNDdbFC9bhqJkReC2uoOLgPj0Eyh++L2Jo5Q@mail.gmail.com>
References: <20252.34118.335900.699784@zaphod.ms25.net>
 <20120123.083130.222913262.wl@gnu.org>
 <CAD5iDTC2PuLXVtRNDdbFC9bhqJkReC2uoOLgPj0Eyh++L2Jo5Q@mail.gmail.com>
Message-ID: <20120123.141447.214284149.wl@gnu.org>


From: Thanh Han The <hanthethanh at gmail.com>
Subject: Re: [pdftex] inclusion of PDF file fails
Date: Mon, 23 Jan 2012 11:32:38 +0100

> pdftex considers two fonts are the same if they have the same
> /FontName (/UniqueID is not used).
> 
> comparing font version is certain a better way to do it, but the
> change is not something like a few lines of code. pdftex must parse
> the font file (from disk) and the font embedded in the pdf. Both are
> doable but not trivial due to the way pdftex handles fonts now.
> 
> In the meantime, perhaps setting \pdfinclusioncopyfonts=1 (as the
> default value at engine level) is the safe thing to do (with the
> risk that some people will blame pdftex for increasing pdf output
> size).

Well, for the PDF manuals of LilyPond, this isn't an option since we
have a few thousands of included PDFs.


    Werner

From reinhard.kotucha at web.de  Mon Jan 23 19:54:14 2012
From: reinhard.kotucha at web.de (Reinhard Kotucha)
Date: Mon, 23 Jan 2012 19:54:14 +0100
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <CAD5iDTC2PuLXVtRNDdbFC9bhqJkReC2uoOLgPj0Eyh++L2Jo5Q@mail.gmail.com>
References: <20111229.082748.18292415.wl@gnu.org>
 <20120122.205017.06687362.wl@gnu.org>
 <20252.34118.335900.699784@zaphod.ms25.net>
 <20120123.083130.222913262.wl@gnu.org>
 <CAD5iDTC2PuLXVtRNDdbFC9bhqJkReC2uoOLgPj0Eyh++L2Jo5Q@mail.gmail.com>
Message-ID: <20253.44246.264009.168366@zaphod.ms25.net>

On 2012-01-23 at 11:32:38 +0100, Thanh Han The wrote:

 > On Mon, Jan 23, 2012 at 8:31 AM, Werner LEMBERG <wl at gnu.org> wrote:
 > >> ?> > While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is
 > >> ?> > version 1.06 (file `c059013l.pfb' from ghostscript), pdftex
 > >> ?> > uses `uncr8a.pfb' from TeXLive, which is version 1.05.
 > >> ?> > Obviously, version 1.05 misses all Cyrillic glyphs. ?IMHO, the
 > >> ?> > right solution is to allow font merging only if the font
 > >> ?> > versions are identical.
 > >> ?>
 > >> ?> Is someone going to fix this?
 > >>
 > >> PdfTeX already merges fonts only if they have the same /FontName and
 > >> /UniqueID.
 > >
 > > But the concept of /UniqueID has been abandonded by Adobe a very long
 > > time ago:
 > >
 > > ?http://typophile.com/node/18749
 > >
 > > (This link is from 2006.) ?So it's actually another bug if pdftex
 > > relies on it.
 > >
 > >> However, ghostschript provides fonts with are buggy in this respect.
 > >> They contain additional glyphs but have the same /FontName and
 > >> /UniqueID as the original URW fonts. ?I don't know how pdfTeX should
 > >> recognize this.
 > >
 > > As I've already mentioned: Use the font's version (1.05 vs. 1.06 in
 > > the example given by me)! ?If someone produces fonts which are
 > > different but have exactly the same identifier, nothing can be done
 > > except punishing the font developer.
 > 
 > pdftex considers two fonts are the same if they have the same
 > /FontName (/UniqueID is not used).
 > 
 > comparing font version is certain a better way to do it, but the
 > change is not something like a few lines of code. pdftex must parse
 > the font file (from disk) and the font embedded in the pdf. Both are
 > doable but not trivial due to the way pdftex handles fonts now.
 > 
 > In the meantime, perhaps setting \pdfinclusioncopyfonts=1 (as the
 > default value at engine level) is the safe thing to do (with the risk
 > that some people will blame pdftex for increasing pdf output size).

Hi, 
maybe this is not necessary.  We had several discussions about this
problem on some TeX related mailing lists already.  Someone forwarded
one of my mails to the ghostscript developers in which I described the
problem.  Chris Liddell considered to revert to the pristine URW fonts
we are also using in TeX Live.

Now I found this at http://bugs.ghostscript.com/show_bug.cgi?id=687297

| Chris Liddell 2011-12-15 16:19:21 UTC
| Partially fixed by reverting to the pristine URW fonts.
|
| This removes the problematic Cyrillic glyphs, and gives us a "clean"
| base to get back to URW with remaining issues.

Seems that we simply have to wait for the next ghostscript release.

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha                                      Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                              mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------


From John at wexfordpress.com  Tue Jan 24 21:18:55 2012
From: John at wexfordpress.com (john Culleton)
Date: Tue, 24 Jan 2012 15:18:55 -0500
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <CAArVCkSsQYsDeeDyHneqbqCfjnKq7v10tCi92+skKsnQUDkyuA@mail.gmail.com>
References: <20111229.082748.18292415.wl@gnu.org>
 <20120122.205017.06687362.wl@gnu.org>
 <CAArVCkSsQYsDeeDyHneqbqCfjnKq7v10tCi92+skKsnQUDkyuA@mail.gmail.com>
Message-ID: <20120124151855.6876fbd9@sda8.wexfordpress.net>

On Sun, 22 Jan 2012 21:42:04 +0100
Philipp Stephani <p.stephani2 at googlemail.com> wrote:

> 2012/1/22 Werner LEMBERG <wl at gnu.org>:
> >
> > A month ago I wrote:
> >
> >> I consider this a bug in pdftex.
> >>
> >> While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is version
> >> 1.06 (file `c059013l.pfb' from ghostscript), pdftex uses
> >> `uncr8a.pfb' from TeXLive, which is version 1.05. ?Obviously,
> >> version 1.05 misses all Cyrillic glyphs. ?IMHO, the right solution
> >> is to allow font merging only if the font versions are identical.
> >
> > Is someone going to fix this?
> 
> Development for PDFTeX has essentially stopped, so I wouldn't hold my
> breath.

Why? Is it because all resources wre devoted to luatex?

-- 
John Culleton
Free list of books for self-publishers:
http://wexfordpress.net/shortlist.html

"Create Book Covers with Scribus"
http://www.booklocker.com/books/4055.html


From reinhard.kotucha at web.de  Tue Jan 24 23:38:29 2012
From: reinhard.kotucha at web.de (Reinhard Kotucha)
Date: Tue, 24 Jan 2012 23:38:29 +0100
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <20120124151855.6876fbd9@sda8.wexfordpress.net>
References: <20111229.082748.18292415.wl@gnu.org>
 <20120122.205017.06687362.wl@gnu.org>
 <CAArVCkSsQYsDeeDyHneqbqCfjnKq7v10tCi92+skKsnQUDkyuA@mail.gmail.com>
 <20120124151855.6876fbd9@sda8.wexfordpress.net>
Message-ID: <20255.13029.956270.671244@zaphod.ms25.net>

On 2012-01-24 at 15:18:55 -0500, john Culleton wrote:

 > On Sun, 22 Jan 2012 21:42:04 +0100
 > Philipp Stephani <p.stephani2 at googlemail.com> wrote:
 > 
 > > 2012/1/22 Werner LEMBERG <wl at gnu.org>:
 > > >
 > > > A month ago I wrote:
 > > >
 > > >> I consider this a bug in pdftex.
 > > >>
 > > >> While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is
 > > >> version 1.06 (file `c059013l.pfb' from ghostscript), pdftex
 > > >> uses `uncr8a.pfb' from TeXLive, which is version
 > > >> 1.05. ?Obviously, version 1.05 misses all Cyrillic
 > > >> glyphs. ?IMHO, the right solution is to allow font merging
 > > >> only if the font versions are identical.
 > > >
 > > > Is someone going to fix this?
 > > 
 > > Development for PDFTeX has essentially stopped, so I wouldn't
 > > hold my breath.
 > 
 > Why? Is it because all resources wre devoted to luatex?

PdfTeX aims for stability now.  It already supports everything which
can be supported by a system which extends Knuth's TeX,  adding
support for Unicode and OTF would mean to write it from scratch, more
or less.

It's still maintained.  In this respect, it's similar to Knuth's TeX.

Is there anything you are missing?

Regards,
  Reinhard

-- 
----------------------------------------------------------------------------
Reinhard Kotucha                                      Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                              mailto:reinhard.kotucha at web.de
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------


From Robin.Fairbairns at cl.cam.ac.uk  Wed Jan 25 00:25:33 2012
From: Robin.Fairbairns at cl.cam.ac.uk (Robin Fairbairns)
Date: Tue, 24 Jan 2012 23:25:33 +0000
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: Your message of Tue, 24 Jan 2012 15:18:55 -0500.
 <20120124151855.6876fbd9@sda8.wexfordpress.net>
Message-ID: <17371.1327447533@cl.cam.ac.uk>

john Culleton <John at wexfordpress.com> wrote:

> On Sun, 22 Jan 2012 21:42:04 +0100
> Philipp Stephani <p.stephani2 at googlemail.com> wrote:
> 
> > 2012/1/22 Werner LEMBERG <wl at gnu.org>:
> > >
> > > A month ago I wrote:
> > >
> > >> I consider this a bug in pdftex.
> > >>
> > >> While the `CenturySchL-Roma' font embedded in `BFEx.pdf' is version
> > >> 1.06 (file `c059013l.pfb' from ghostscript), pdftex uses
> > >> `uncr8a.pfb' from TeXLive, which is version 1.05. ?Obviously,
> > >> version 1.05 misses all Cyrillic glyphs. ?IMHO, the right solution
> > >> is to allow font merging only if the font versions are identical.
> > >
> > > Is someone going to fix this?
> > 
> > Development for PDFTeX has essentially stopped, so I wouldn't hold my
> > breath.
> 
> Why? Is it because all resources wre devoted to luatex?

no, because the pdftex developers decided they had had enough.

the luatex team was formed to produce a specific product; money is
involved, whereas there's no money involved in pdftex development.

robin


From vivrii at gmail.com  Wed Jan 25 00:31:54 2012
From: vivrii at gmail.com (Victor Ivrii)
Date: Tue, 24 Jan 2012 18:31:54 -0500
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <20255.13029.956270.671244@zaphod.ms25.net>
References: <20111229.082748.18292415.wl@gnu.org>
 <20120122.205017.06687362.wl@gnu.org>
 <CAArVCkSsQYsDeeDyHneqbqCfjnKq7v10tCi92+skKsnQUDkyuA@mail.gmail.com>
 <20120124151855.6876fbd9@sda8.wexfordpress.net>
 <20255.13029.956270.671244@zaphod.ms25.net>
Message-ID: <CADP=ZZrjzjSsW1iMf8iuMRH2gyKSNFsQa7dm8LgV3v7sewq+tw@mail.gmail.com>

On Tue, Jan 24, 2012 at 5:38 PM, Reinhard Kotucha
<reinhard.kotucha at web.de> wrote:
> On 2012-01-24 at 15:18:55 -0500, john Culleton wrote:
>

>
> PdfTeX aims for stability now. ?It already supports everything which
> can be supported by a system which extends Knuth's TeX, ?adding
> support for Unicode and OTF would mean to write it from scratch, more
> or less.
>
> It's still maintained. ?In this respect, it's similar to Knuth's TeX.
>
> Is there anything you are missing?
>

My limited experience with lualatex shows that it is backward
compatible with pdflatex and if some front-end comes with the default
engine lualatex instead of pdflatex, 99% of users would not notice
this.

I am missing the respect to links (internal or external) when
including pdf (via pdfpages f.e., attachfile is a





> Regards,
> ?Reinhard
>
> --
> ----------------------------------------------------------------------------
> Reinhard Kotucha ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Phone: +49-511-3373112
> Marschnerstr. 25
> D-30167 Hannover ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:reinhard.kotucha at web.de
> ----------------------------------------------------------------------------
> Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
> ----------------------------------------------------------------------------
>



-- 
========================
Victor Ivrii, Professor, Department of Mathematics, University of Toronto
http://www.math.toronto.edu/ivrii


From Jim.Diamond at acadiau.ca  Wed Jan 25 00:39:28 2012
From: Jim.Diamond at acadiau.ca (Jim Diamond)
Date: Tue, 24 Jan 2012 19:39:28 -0400
Subject: [pdftex] inclusion of PDF file fails
In-Reply-To: <CADP=ZZrjzjSsW1iMf8iuMRH2gyKSNFsQa7dm8LgV3v7sewq+tw@mail.gmail.com>
References: <20111229.082748.18292415.wl@gnu.org>
 <20120122.205017.06687362.wl@gnu.org>
 <CAArVCkSsQYsDeeDyHneqbqCfjnKq7v10tCi92+skKsnQUDkyuA@mail.gmail.com>
 <20120124151855.6876fbd9@sda8.wexfordpress.net>
 <20255.13029.956270.671244@zaphod.ms25.net>
 <CADP=ZZrjzjSsW1iMf8iuMRH2gyKSNFsQa7dm8LgV3v7sewq+tw@mail.gmail.com>
Message-ID: <20120124233928.GA32523@jdiamond-nb2>

On Tue, Jan 24, 2012 at 18:31 (-0500), Victor Ivrii wrote:

> On Tue, Jan 24, 2012 at 5:38 PM, Reinhard Kotucha
> <reinhard.kotucha at web.de> wrote:
>> On 2012-01-24 at 15:18:55 -0500, john Culleton wrote:



>> PdfTeX aims for stability now. ?It already supports everything which
>> can be supported by a system which extends Knuth's TeX, ?adding
>> support for Unicode and OTF would mean to write it from scratch, more
>> or less.

>> It's still maintained. ?In this respect, it's similar to Knuth's TeX.

>> Is there anything you are missing?


> My limited experience with lualatex shows that it is backward
> compatible with pdflatex and if some front-end comes with the default
> engine lualatex instead of pdflatex, 99% of users would not notice
> this.

You may be correct about 99%, but unfortunately it has the same bug
with \magnification that pdftex had a long time ago.  Namely, using
\magnification also magnifies the page size, unlike TeX, where after a
\magnification the page is still the original page size.

				Jim