On 2004-01-29 01:15:49 +0100, Staszek Wawrykiewicz wrote:
> can you tell me about the status of expected changes to pdf(e)tex?
Stasz,
I want to fix the cfg problem in the next release (1.12a, planned
for early February).
> Just to recall, here is the current problem:
> how to avoid reading pdftex.cfg while running pdf(e)tex --ini
As I recall the main problem was not that a cfg was found and read
but that it wasn't found and pdftex failed. I just want to make a
missing cfg a non-fatal error.
> I would vote for dumping the *default* output to the format, say
> latex will use \pdfoutput=0, pdflatex will use \pdfoutput=1
Good idea.
> So latex etc. could be linked just to pdfetex, without any other
> command line switch (anyway not yet available). For such command&format
> I'd suggest not reading pdftex.cfg at all (it sets things rather
> concerned to pdf output).
>
> pdftex.cfg should be left as it is for commands&formats
> which use pdf output by default. Just to avoid a mess with new
> command line parameters for pdf(e)tex, more config files,
> and... for transparent use as (e)tex replacement as the main
> engine (actually not true).
True.
> Ps. I'm overflooded by spam mails, often sent from your, Sebastian
> and other people addresses...
Yes. Spammers like to fake their addresses and use publically
known addresses. Unfortunately ours are all over the web. :-(
Use SpamAssassin with procmail. :-(
Best regards
Martin
--
Martin Schröder, ms(a)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
>Hi Martin,
>
>Occasionally we need to have access to the llx/lly coordinates of a
>graphic; in EPS this is no problem, but ...
>
>how about providing \pdfxformllx\xformid (etc: llx, lly, ulx, uly)
>
>(background: Ross/Wendy/Me are working on label overlay features [there
>is/will be a plug in for AI to provide some of the info needed] and fro
>that we need to have access to the "origin"
>
>Hans
-------------------------------------------------------------------------
Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
information: http://www.pragma-ade.com/roadmap.pdf
documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------
This means pdf1.5 is on the horizon and will be in 1.2 (which should
be there before BachoTeX).
Best regards
Martin
--
Martin Schröder, ms(a)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-01-18 18:25:48 +0100, Hans Hagen wrote:
> So, martin: is there any reason for an abort when no config is found?
> Defaulting to outut_format 0 also honors Staszeks wish to default to dvi
I don't see any; in fact I think it's a bug to abort when no
config can be found.
I'll fix it.
Best regards
Martin
--
Martin Schröder, ms(a)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
Hi,
currently missing encoding files and missing pfbs only generate
warnings and lead to incorrect pdfs.
Any objections against turning these warnings into errors?
The same probably applies to mapfiles.
Best regards
Martin
--
Martin Schröder, ms(a)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
At 23:00 04/01/2004, you wrote:
>hi hans: this would be great news, indeed. (I liked \include{} because
>it requires an operating system file system operation, just like current
>file name/date). if you are addings this, please add individual filename
>date/time, too, not just jobdate. I would also add a "\system{}" macro,
>instead of a write18 macro, where the output is directly inserted as text
>into the output stream; it would be mildly safer than write18, and more
>functional in most situations.
an option for that could be something:
\openin\tempread=somename.suffix
\pdffiledate\tempread
\pdffilesize\tempread
etc.
This has several advantages: (1) it runs on top of the current file
mechanism, (2) is can work with the kpse file search library (handy when
the path is not known) and (3) implementing anything too far from tex's
internals can be tricky with regards to how it end up in the string pool etc.
With regards to \system{...}, maybe some pipe could be implemented,
\immediate\openin\read18{whatever}
or so ...
>I actually am surprised that this feature still needs a lot of work to
>work on many different systems. I would guess Unix systems (including
>Mac) and Windows machines these days all work pretty much the same way to
>get datefile /time via a stat() call. Compilers with Unix+Win
>compatibility just have to cover 99% of all TeX installation these
>days. And, if this feature does not work on a particular system, it won't
>break the world---just the same as when write18 does not work or when
>\today outputs the wrong date or no date on a system that does not keep
>time. (ok, so they no longer exist.)
it has to with the fact that extension are implemented on top of 25 years
of accumulated tex code (a mix of pascal and c and libraries); also, tex is
(and has to be) extremely reliable since it's used all over the world, also
by non system experts and hackers, so every extension should *work*, i.e.
in this respect tex is not like the average open source thing, there is so
much related and derived stuff around, and compatibility is not only a big
issue here, but also the reason that tex is still around; on the other
hand, extension are possible and part of the game, so in the end ...
> -----Original Message-----
> From: Hans Hagen [mailto:pragma@wxs.nl]
> Sent: Sun 1/4/2004 1:42 PM
> To: Welch, Ivo
> Cc:
> Subject: Re: [pdftex] current filename and current filedate ?
>
>
>
> At 02:46 20/12/2003, you wrote:
>
> >* Programming-wise, it would not be a big step to add two macros for
> >\currentfile and \currentfiledate. There is no operating system
> on which
> >this would likely be difficult. Are there any modern C
> implementations
> >without a basic Unix-like stat() call?
>
> Already on the pdftex 'to be implemented in a next release list are'
>
> \pdfhours
> \pdfminutes
> \pdfseconds
> \pdfmilliseconds
>
> (needed since \time is too unprecise, which renders it useless
> for for
> instance random number generation); so there is no problem for adding
>
> \pdfjobnamedate
> \pdfjobnamesize
> \pdfjobfullpath
>
> Such extensions may sound trivial but since their implementation is
> platform independent [which has consequences in many small areas
> of the
> source code tree] they end up on to do lists (next major release);
>
> >* We already have facilities inside latex to get the overall
> \jobname
> >(really a filename). We also already have facilities for the
> current
> >date/time.
>
> hm, \jobname is special in itself, it's also an example of the
> mess you may
> end up in: catcodes of tokens in reported filename in this case
>
> >So, if we can have \write18, \include, and \jobname,
> \currentfile and
> >\currentfiledate is not very different.
>
> what's \include suppose to do?
>
> Hans
>
>
-------------------------------------------------------------------------
Hans Hagen | PRAGMA ADE | pragma(a)wxs.nl
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
information: http://www.pragma-ade.com/roadmap.pdf
documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------
