Re: pdfetex as the only engine
On 2004-03-07 07:48:45 -0500, Sebastian Rahtz wrote:
excellent.
Indeed. Fabrice, please submit your patches to TL. Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On 2004-03-07 07:48:45 -0500, Sebastian Rahtz wrote:
excellent.
Indeed. Fabrice, please submit your patches to TL.
Change #4457 (without ^M !). Please check it as my own source tree can't give a clean patch (other things are in the way). Fabrice
On Mon, 8 Mar 2004, Fabrice Popineau wrote:
Change #4457 (without ^M !). Please check it as my own source tree can't give a clean patch (other things are in the way).
Failed to compile on linux (even with change #4458) :( Something wrong near making config.c needed by config.o Please register changes in NEWS. Thanks. -- Staszek Wawrykiewicz StaW@gust.org.pl
Failed to compile on linux (even with change #4458) :( Something wrong near making config.c needed by config.o Please register changes in NEWS. Thanks.
It should get compiled ... Please remove config.[co] from web2c/pdftexdir/depend.mk and from web2c/pdftexdir/Makefile.in. Ok, I'll send a patch to NEWS file. The patch submission was for review in my mind. I expect feedback. Fabrice
On 2004-03-09 12:15:19 +0100, Fabrice Popineau wrote:
Ok, I'll send a patch to NEWS file. The patch submission was for review in my mind. I expect feedback.
It compiles and works. You removed the support for cfg files completely, which is not backwards compatible (but cfg files will be at a new place anyway). I'd prefer it if a found cfg would still be read (i.e. the code from 1.11b just stays in), but new configuration options will not be available through the cfg (i.e. the use of cfg will only be deprecated). The priorities for configuration should be input, cfg and fmt in descending precedence. Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On 2004-03-09 12:15:19 +0100, Fabrice Popineau wrote:
Ok, I'll send a patch to NEWS file. The patch submission was for review in my mind. I expect feedback.
It compiles and works.
Thanks.
You removed the support for cfg files completely, which is not backwards compatible (but cfg files will be at a new place anyway).
I'd prefer it if a found cfg would still be read (i.e. the code from 1.11b just stays in), but new configuration options will not be available through the cfg (i.e. the use of cfg will only be deprecated).
The priorities for configuration should be input, cfg and fmt in descending precedence.
I can agree and restore pdftex.cfg reading, but that may result in a mess to understand why pdf_output is such or such value. Fabrice
On 2004-03-09 22:00:55 +0100, Fabrice Popineau wrote:
The priorities for configuration should be input, cfg and fmt in descending precedence.
I can agree and restore pdftex.cfg reading, but that may result in a mess to understand why pdf_output is such or such value.
Yes. And it would make dumping pdf_output in the format superfluous. So we simply drop the cfg? Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On Tue, 9 Mar 2004, Martin [iso-8859-1] Schröder wrote:
On 2004-03-09 22:00:55 +0100, Fabrice Popineau wrote:
The priorities for configuration should be input, cfg and fmt in descending precedence.
I can agree and restore pdftex.cfg reading, but that may result in a mess to understand why pdf_output is such or such value.
Yes. And it would make dumping pdf_output in the format superfluous.
??? As I understand, dumping pdf_output in the format is the main advantage, so running 'latex foo' will just output foo.dvi and 'pdflatex foo' will output foo.pdf It seems that things now works well, so many thanks for doing the last changes. Only some notes: 1. world.log says for every pdf* -ini run output format initialized to DVI fortunatelly .ini file is then read and proper output is set here, so the result is OK (for the first moment I was in trouble reading that ;-) 2. pdftex.ini \input bplain instead of plain.tex This problem returns again and again... Why on hell!? 3. it is perhaps good time to remove pdfelatex and elatex (Fabrice already did that for win32). This would be one more step towards removing other engines/links. MS>> So we simply drop the cfg? FP> That's what I would do. Unless someone has strong objection. Perhaps Hans? I remember that he has some arguments for using cfg Ps. I've submited new i386-linux binaries upto #4464 -- Staszek Wawrykiewicz StaW@gust.org.pl
Staszek> ??? As I understand, dumping pdf_output in the format is the Staszek> main advantage, so running 'latex foo' will just output Staszek> foo.dvi and 'pdflatex foo' will output foo.pdf Actually, you can even run latex --output-format=pdf foo :-) Staszek> 1. world.log says for every pdf* -ini run output format Staszek> initialized to DVI I must admit that it is a bit misleading. But if there is only one engine, its ini version output format has to be initialized to DVI. Then only \pdfoutput=1 will switch it to PDF and eventually will be dumped. Maybe the problem is that you just don't expect from inipdfetex to be initialized to DVI output format ... Any suggestion to make it more clear ? Fabrice
Actually, you can even run latex --output-format=pdf foo
Well, to get something useful, you have to make sure that the latex format is created with useful setting for e.g. \pdfhorigin and \pdfvorigin. If you just latex -ini latex.ltx latex --output-format=pdf sample2e you'll get a messed-up sample2e.pdf. This means, that we either have to make sure to set useful defaults for *all* formats that we dump with pdfetex or that we reactivate the config file.
Maybe the problem is that you just don't expect from inipdfetex to be initialized to DVI output format ...
Maybe, pdf*tex should defer this message until the dvi vs. pdf decision is finally decided (don't know when this is: when typesetting the first boxes or when shipping out the first page). Thomas
Actually, you can even run latex --output-format=pdf foo
Well, to get something useful, you have to make sure that the latex format is created with useful setting for e.g. \pdfhorigin and \pdfvorigin.
If you just latex -ini latex.ltx latex --output-format=pdf sample2e you'll get a messed-up sample2e.pdf.
This means, that we either have to make sure to set useful defaults for *all* formats that we dump with pdfetex or that we reactivate the config file.
Surely those variables must be intialized with sensible values ? But when I wrote that, I meant that we probably can't expect that every package will take care of potential pdf output. So my question is : shouldn't we allow to switch pdf_output on command line only in INI mode ?
Maybe the problem is that you just don't expect from inipdfetex to be initialized to DVI output format ...
Maybe, pdf*tex should defer this message until the dvi vs. pdf decision is finally decided (don't know when this is: when typesetting the first boxes or when shipping out the first page).
That makes sense. Fabrice
On 2004-03-11 09:15:30 +0100, Fabrice Popineau wrote:
Maybe, pdf*tex should defer this message until the dvi vs. pdf decision is finally decided (don't know when this is: when typesetting the first boxes or when shipping out the first page).
That makes sense.
Yes. The current version is bizarre:
pdftex -ini This is pdfTeXk, Version 3.141592-1.12b-beta-20040309 (Web2C 7.5.2) (INITEX) %&-line parsing enabled. **\pdfoutput=1 output format initialized to DVI
Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On 2004-03-10 03:31:29 +0100, Staszek Wawrykiewicz wrote:
Ps. I've submited new i386-linux binaries upto #4464
ldd /home/ms/tex/texlive/Master/bin/i386-linux/pdftex /home/ms/tex/texlive/Master/bin/i386-linux/pdftex: /lib/libc.so.6: version `GLIBC_2.2.4' not found (required by /home/ms/tex/texlive/Master/bin/i386-linux/pdftex) /home/ms/tex/texlive/Master/bin/i386-linux/pdftex: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /home/ms/tex/texlive/Master/bin/i386-linux/pdftex) libm.so.6 => /lib/libm.so.6 (0x4002d000) libc.so.6 => /lib/libc.so.6 (0x4004c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
:-( Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On Wed, 10 Mar 2004, Martin [iso-8859-1] Schröder wrote:
On 2004-03-10 03:31:29 +0100, Staszek Wawrykiewicz wrote:
Ps. I've submited new i386-linux binaries upto #4464
ldd /home/ms/tex/texlive/Master/bin/i386-linux/pdftex /home/ms/tex/texlive/Master/bin/i386-linux/pdftex: /lib/libc.so.6: version `GLIBC_2.2.4' not found (required by /home/ms/tex/texlive/Master/bin/i386-linux/pdftex) /home/ms/tex/texlive/Master/bin/i386-linux/pdftex: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /home/ms/tex/texlive/Master/bin/i386-linux/pdftex) libm.so.6 => /lib/libm.so.6 (0x4002d000) libc.so.6 => /lib/libc.so.6 (0x4004c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Ehh... what can we do? Make static everything or using old RH6.2 for compilation (I'm still keeping such old bet). -- Staszek Wawrykiewicz StaW@gust.org.pl
Ehh... what can we do? Make static everything or using old RH6.2 for compilation (I'm still keeping such old bet).
I guess that's the best you can do. IIRC, you even had a static version of the Xaw library which you had linked in "by hand" (for xdvi, not pdftex related). Thomas
On Wed, 10 Mar 2004, Thomas Esser wrote:
Ehh... what can we do? Make static everything or using old RH6.2 for compilation (I'm still keeping such old bet).
I guess that's the best you can do. IIRC, you even had a static version of the Xaw library which you had linked in "by hand" (for xdvi, not pdftex related).
OK, will do. Thanks, -- Staszek Wawrykiewicz StaW@gust.org.pl
On 2004-03-10 20:05:36 +0100, Staszek Wawrykiewicz wrote:
Ehh... what can we do? Make static everything or using old RH6.2 for compilation (I'm still keeping such old bet).
More or less. This from TL2003:
ldd /usr/local/bin/pdftex libm.so.6 => /lib/libm.so.6 (0x4002d000) libc.so.6 => /lib/libc.so.6 (0x40050000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
On 2004-03-09 22:00:55 +0100, Fabrice Popineau wrote: So we simply drop the cfg?
where to set default papersize? Hartmut (deserted with a webmailer only) -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
At 09:15 10/03/2004, Hartmut Henkel wrote:
On 2004-03-09 22:00:55 +0100, Fabrice Popineau wrote: So we simply drop the cfg?
where to set default papersize?
in the document, since the macro package needs to handle the dimensions anyway; pdftex/tex live should not be papersize dependent; since the development takes place in europe/asia, i suggest to hardwire A4 as default Hans
where to set default papersize?
in the document, since the macro package needs to handle the dimensions anyway; pdftex/tex live should not be papersize dependent; since the development takes place in europe/asia, i suggest to hardwire A4 as default
also something for texmf.cnf? It's also a systemwide parameter. Even pick from libpapersize by kpathsea? Regards, Hartmut ---slowly convinced about the .cnf drop, and the main thing i did until now with the manual was to rearrange .cnf descriptions... -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
At 11:27 10/03/2004, Hartmut Henkel wrote:
where to set default papersize?
in the document, since the macro package needs to handle the dimensions anyway; pdftex/tex live should not be papersize dependent; since the development takes place in europe/asia, i suggest to hardwire A4 as default
also something for texmf.cnf? It's also a systemwide parameter. Even pick from libpapersize by kpathsea?
Regards, Hartmut
---slowly convinced about the .cnf drop, and the main thing i did until now with the manual was to rearrange .cnf descriptions...
that will not change, since it can be turned into: "You can make a configuration file for pdftex as follows: ...." so, only the \pdf prefix needs to be added; the discriptions are still valid Hans
So we simply drop the cfg?
What about sysadmins who currently have map pdftex.map map +localfonts.map I.e. it used to be easy to make additional map files generally available. Should this information now be sumped into the format, too (via manipulated .ini files)? Somehow, I feel that we loose something if we drop the config file entirely. Can't we just avoid reading pdfoutput from the config file (and issue a warning that we ignore the setting from the config file)? Or, are there more reasons to drop the config file? Thomas
On 2004-03-10 09:41:12 +0100, Thomas Esser wrote:
What about sysadmins who currently have map pdftex.map map +localfonts.map
How many do?
I.e. it used to be easy to make additional map files generally available. Should this information now be sumped into the format, too (via manipulated .ini files)?
That would be the obvious approach: Everything that can now be done with pdftex.cfg must then be possible throug commands in the input.
Somehow, I feel that we loose something if we drop the config file entirely. Can't we just avoid reading pdfoutput from the config file (and issue a warning that we ignore the setting from the config file)?
That's an option. Who needs the cfg anyway? Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de
map pdftex.map map +localfonts.map How many do?
Well, I don't think that we should try to guess numbers of users of some features. Let's talk about use-cases and how they can be handled. One use-case of the config file is to have a copy of it in the local tree. One can set up additional map files there which also reside in the local tree. That way, one can easily replace/upgrade the whole TeX system (keeping the local tree in place, of course) without having any need to re-enable the additional map files. I am not afraid of changes, but I'd be not so happy to loose this functionality completely. Thomas
At 09:41 10/03/2004, Thomas Esser wrote:
So we simply drop the cfg?
yes
What about sysadmins who currently have map pdftex.map map +localfonts.map
I.e. it used to be easy to make additional map files generally available.
most users will use the big map file
Should this information now be sumped into the format, too (via manipulated .ini files)?
just put it in a variable in the texmf.cnf file
Or, are there more reasons to drop the config file?
confusion is one of them Hans
At 23:27 09/03/2004, you wrote:
On 2004-03-09 22:00:55 +0100, Fabrice Popineau wrote:
The priorities for configuration should be input, cfg and fmt in descending precedence.
I can agree and restore pdftex.cfg reading, but that may result in a mess to understand why pdf_output is such or such value.
Yes. And it would make dumping pdf_output in the format superfluous.
So we simply drop the cfg?
yes Hans
participants (6)
-
Fabrice Popineau -
Hans Hagen -
Hartmut Henkel -
Martin Schröder -
Staszek Wawrykiewicz -
Thomas Esser