On 2002-10-28 13:13:19 +0100, Martin Schröder wrote:

Is there an easy way to fix this?

It seems the easiest would be to not use the p4-$DateTime$ but generate new version strings from a script which also does the submit. I'll tackle that tomorrow. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-10-31 06:33:47 +0100, Olaf Weber wrote:

On a related note -- any idea when you'll be able to make a release?

I'm currently integrating xpdf 2.00; after that I vote for a release. Let's have a release this year. :-} Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-11-11 17:52:53 +0100, Martin Schröder wrote:

I'm currently integrating xpdf 2.00; after that I vote for a

That's finished; please test the current version thoroughly. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-11-11 20:08:46 +0100, Hartmut Henkel wrote:

Where do I find the current version?

In the repository. :-) And Thomas has integrated it into the latest teTe-beta. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-11-14 01:27:44 +0100, Fabrice Popineau wrote:

Currently, I have problems (ie: seg fault) when including pdf files and it seems to occur every time. The obj1 object in web2c/pdftexdir/pdftoepdf.cc:write_pdf() function does not seem to have a proper dict attribute (most of the fields of its dict attribute are set to null values).

For me it stopped even further: pdftex_fail("xpdf: reading PDF image failed"); This seems to be because xpdf was compiled with DISABLE_OUTLINE. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-11-14 16:04:37 +0100, Martin Schröder wrote:

On 2002-11-14 01:27:44 +0100, Fabrice Popineau wrote:

...

Currently, I have problems (ie: seg fault) when including pdf files and it seems to occur every time. The obj1 object in web2c/pdftexdir/pdftoepdf.cc:write_pdf() function does not seem to have a proper dict attribute (most of the fields of its dict attribute are set to null values).

I think I've found it; it's in the replacements for initDict (dict).

Any idea why replacing obj1->initDict(obj->getStream()->getDict()); with obj1->initDict(xref); dict = obj->streamGetDict(); for (i = 0, l = dict->getLength(); i < l; i++) { dict->getVal(i, &obj3); obj1->dictAdd(dict->getKey(i), &obj3); } in copyObject leads to a SIGSEV in writeRefs or how to code this right? Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-11-14 10:05:14 -0800, Derek B. Noonburg wrote:

You need to copy the key string:

obj1->dictAdd(copyString(dict->getKey(i)), &obj3);

And we need to use Objects and not PDFObjects. This works: // Replacement for // Object *initDict(Dict *dict1){ initObj(objDict); dict = dict1; return this; } static void initDictFromDict (PdfObject &obj, Dict *dict) { Object obj1; int i, l; obj->initDict(xref); for (i = 0, l = dict->getLength(); i < l; i++) { obj->dictAdd(copyString(dict->getKey(i)), dict->getVal(i, &obj1)); } } Two questions on Dict.h: Object *getVal(int i, Object *obj); Object *getValNF(int i, Object *obj); - What's the difference between those functions? - What purpose has the obj parameter since the value is returned? Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-11-14 16:04:37 +0100, Martin Schröder wrote:

On 2002-11-14 01:27:44 +0100, Fabrice Popineau wrote:

...

Currently, I have problems (ie: seg fault) when including pdf files and it seems to occur every time. The obj1 object in web2c/pdftexdir/pdftoepdf.cc:write_pdf() function does not seem to have a proper dict attribute (most of the fields of its dict attribute are set to null values).

I think I've found it; it's in the replacements for initDict (dict).

It's fixed. Get the latest version. :-) Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-11-16 15:19:11 +0100, Hartmut Henkel wrote:

the simple changes below in pdftex.ch make pdftex.w weave/texable without error stops. In the original pdftex.ch there are some code sections commented out; as these are treated as text, tex complains about unescaped underscores. Here's the patch, which makes these comments literal code (I like to have pdftex.dvi easily generated):

Thanks, I've incorporated them. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

I'm currently integrating xpdf 2.00; after that I vote for a release. Let's have a release this year. :-}

I'd love to release teTeX-2.0 together with the next pdftex release, a stable omega and a more secure dvips *this year*. Yes, that would be great! Olaf Weber will soon release web2c-7.4.0 if there are no major problems with web2c-7.3.10 (released today). I'll try to keep the perforce tree up to date with everything that I can contribute. Thomas

On 2002-12-09 16:28:02 +0100, Martin Schröder wrote:

Thanh, can you please give the current state your lessing?

s/less/bless/ :-) Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-12-10 09:22:45 +0700, Han The Thanh wrote:

In short: if it's not so urgent, I would delay the release a few months.

That would move pdfTeX to yearly releases. :-( The problem is: We already _have_ a release everytime Thomas or Olaf make a new beta (or even do a real release). These betas are used by people -- especially the teTeX-betas. Not doing a pdfTeX release every so often will mean that eventually everyone will use some kind of 1.10-beta-200xxxxx, which we surely don't want. And this will happen when the next Linux distribution decides to package the then-current teTeX-beta. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-12-10 22:22:48 +0700, Han The Thanh wrote:

then it's urgent. so feel free to change the banner and make a release to get rid of it. At least we will have a release without tiff and encryption.

Good. I've changed the banner to 1.10a-RC1. Olaf & Thomas, can you please do a new beta release soon? I'd like the current code to be tested for a week or so before we do a real release. No need to have 1.10b really soon. :-) Sebastian, how do we do a release of pdftex with p4? Shall I change the banner in devel, you integrate it, and I change the banner again to 1.10b-beta-200212xx after that? Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

Good. I've changed the banner to 1.10a-RC1. Olaf & Thomas, can you please do a new beta release soon? I'd like the current code

I have released a new teTeX-beta yesterday. I think, that was "soon enough" :-) ftp://cam.ctan.org/tex-archive/systems/unix/teTeX-beta/teTeX-src-beta-20021210.tar.gz Thomas

On Thu, 2002-12-19 at 15:19, Martin Schroeder wrote:

If we want a release this year, it must be today or tomorrow (or you do it without me). I'll be out of office in W52 and W1 and ArtCom may be without internet access W2 (we're moving and the new building isn't connected yet :-().

I suggest that you make the banner change to pdftex now and leave it ready to release -- Sebastian Rahtz OUCS

On 2002-12-19 14:26:19 +0100, Sebastian Rahtz wrote:

I suggest that you make the banner change to pdftex now and leave it ready to release

We have a very likely fix from Fabrice for the problems with too many open files. I suggest we include this and go through an -RC2 with a possible release date in W1. Or we release -RC1 now and 1.10b with the fix in W2/W3. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

On 2002-12-19 16:04:00 +0100, Sebastian Rahtz wrote:

On Thu, 2002-12-19 at 17:02, Martin Schroeder wrote:

...

We have a very likely fix from Fabrice for the problems with too many open files. I suggest we include this and go through an -RC2 with a possible release date in W1. Or we release -RC1 now and 1.10b with the fix in W2/W3.

what are these Ws?

Weeks. See http://www.cl.cam.ac.uk/~mgk25/iso-time.html

if you have a fix, lets get it in. no sense releasing 1.10 with a known problem...

It's in. change 2606. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

Thomas Esser writes:

...

If we want a release this year, it must be today or tomorrow (or you do it without me). I'll be out of office in W52 and W1 and ArtCom may be without internet access W2 (we're moving and the new building isn't connected yet :-().

Thomas, how near are you teTeX 2.0?

I am waiting for web2c-7.4.1 (as suggested by Olaf Weber). So, I don't think that I can make the release this year.

I've just put out 7.4.1, which should be current, except for two known issues: - MS Windows does not work. - pdfTeX is still only RC3. -- Olaf Weber (This space left blank for technical reasons.)

On 2002-12-20 22:34:13 +0100, Martin Schröder wrote:

On 2002-12-20 20:55:56 +0100, Olaf Weber wrote:

...

- pdfTeX is still only RC3.

I think we are almost there. Maybe we can do a christmas-release. :-)

I've just integrated patch1 for xpdf and increased the T1_BUF_SIZE. Any bugs remaining that need to be fixed now? Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10

Olaf Weber writes:

Martin Schroeder writes:

...

On 2002-12-20 22:34:13 +0100, Martin Schröder wrote:

...

On 2002-12-20 20:55:56 +0100, Olaf Weber wrote:

...

...

...

- pdfTeX is still only RC3.

...

...

I think we are almost there. Maybe we can do a christmas-release. :-)

...

I've just integrated patch1 for xpdf and increased the T1_BUF_SIZE. Any bugs remaining that need to be fixed now?

None that I can think of. However, I won't be able to work on web2c this evening, so you can sleep a night on it as far as I'm concerned. :-)

Martin, As you may know, DEK made a new release of TeX available for beta testing. I'd really like to see teTeX 2.0 pushed out before trying to integrate those changes. So where do we stand now? -- Olaf Weber (This space left blank for technical reasons.)

On Thu, 2003-01-16 at 15:12, Martin Schroeder wrote:

On 2003-01-09 22:33:11 +0100, Olaf Weber wrote:

...

So where do we stand now?

I think we should do a release now.

Sebastian, would you please integrate the sources? have you take RC off the banners?

And we need to update Master/texmf/doc/pdftex/base/pdftex-syntax.txt -- can I do that?

yes, sure. please go ahead -- Sebastian Rahtz OUCS

Hi pdfTeX fans, this is to announce that there is a rewrite of my fun-project JBIG2 pdfTeX driver, see www.circuitwizard.de, if you like. It now slowly starts getting structured and working on multiple images from given JBIG2 files. The driver marks only the page0 segments for putting into a JBIG2Globals object, which are actually referenced by the used JBIG2 images; this shall minimize PDF file size. Hope such approach is allowed. The JBIG2 driver is planned to do autonomously all of its bookkeeping about JBIG2 files and their images and segments, to keep the pdfTeX interface simple (it currently forgets to xfree anything, sorry :-) You can now request two JBIG2 images by e. g.: \pdfximage width \hsize page 1 {foo-multi.jb2} \pdfximage width \hsize page 3 {foo-multi.jb2} The driver (recursively) marks only the page0 segments required for these images and---if page0 segments exist---reserves one JBIG2Globals PDF object per file (straight-forward to Adobe's JBIG2Globals spec.). Now, at the end of the pdfTeX run, I have the problem that I'm sitting on top of a bunch of such page0 segments, and don't know how to get rid of them. I cannot write e. g. \pdfximage page 0 {jbig2-multi.jb2} to flush any accumulated page0 info from that file only, as this creates a new PDF image object, which is not the wanted thing. What I would need is a single function call from the pdfTeX side to a function (which I can provide) to flush all page0 segments of any JBIG2 file accessed during the pdfTeX run into corresponding JBIG2Globals objects, right before the PDF file is finalized. That's my main problem here, so to say: I'm stymied. Any advice greatly welcomed! Best Regards Hartmut

The flagging of required page0 segments is already done, the problem is the later part, namely to flush them out. Who would trigger this? It's not up to the user, as he can until the very end decide to include yet another image from a given JBIG2 file---which might also increase the set of required page0 segments from that JBIG2 file. The PDF spec gives one JBIG2Globals object, which may be referenced by several images. To use this in a natural way means to make one JBIG2Gobals object per JBIG2 file (or none, if not required). This object must contain at least all page0 segments, which are referenced by the selected subset of images from that JBIG2 file. If only a subset of images is extracted from the JBIG2 file, there remain page0 segments, which are not required for the decoding, and therefore do not need to be included in the PDF file. If one includes ALL page0 segments from a JBIG2 file rightaway, it won't hurt, but several page0 segments are then unreferenced (as the referencing images are missing), which is a (probably big) waste of PDF file size. Putting the burden of deciding when to flush page0 segments on the user would mean, that he has to tell, which is the LAST real image included from a given JBIG2 file. If he then flushes out the page0 segments of that file, later inclusion of yet another image from the same file would again require to create a fresh JBIG2Globals object, which is doubling of information in the PDF file. And, if the user forgets to flush page0 stuff, the JBIG2 decoder of the reader will crash. The way I try is to quietly mark required page0 segments as images are included and wait to the very end (this +/- works), and then to flush them out without user interaction, which fills one JBIG2Globals stream per JBIG2 file. Basically what I need is that, about at the time when the user says \end, a call to a function e. g. flushallpages0() is done. The function itself ist straight-forward. Greetings Hartmut On Wed, 8 Jan 2003, Hans Hagen wrote:

i'm not sure if i understand the problem well, but can't you use call to \pdfrefximage to set flags?

\pdfximage page 1 ... -> loads zero thing \pdfrefximage [this image obj number] -> sets flag on associated zero thing

so, in the and you just flush the zero things that are flagged.

Hans

* Olaf Weber writes:

- MS Windows does not work.

I have the patch for kpathsea/tex-make.c, but I still have many things quite different from the current release and that don't plug easily in it. I'll try to submit the small patch this evening or tomorrow, but I would say that basically, you shouldn't wait too much on windows : as soon as 7.4.1 is official, I'll upload new win32 binaries, and my sources won't be exactly the same. I don't know how to deal with it, except by stepping back on several issues. Fabrice

* Olaf Weber writes:

Right now I've got a couple of things in the pipeline, including reworking parts of kpathsea (which may allow me to meet you on these "issues", but which will also make integration "interesting") and reworking the way the build system works (which also may have implications.)

Great!

Finally, I was wondering what's up with those .rc files that I find all over the place in the texlive source tree. They seem to contain version and banner info for windows, but fair number of them appears to be outdated.

Yes, these are resource files which provide some data to be fed into the .exe. They used to be into some separate directory, but somehow, they are really part of the executable file, so should be provided with the other source files. However, as you noticed I didn't find enough time to update them. Fabrice

* Olaf Weber writes:

Duplication of volatile data (and version info is just that) is really bad idea. Can their generation be automated?

I'll think about it. But I guess I will always need to feed the actuall program version somewhere. I agree that for .exe, it is not really useful, but it can be for .dll, even if the .dll mess has not been sorted out in the large. Also, .rc files could be used in principle to store .fmt data for example. This is what is done for xemacs.exe : the dumped data are merged in the resource area of the executable. Fabrice

On 2002-10-28 17:51:23 +0100, Martin Schröder wrote:

It seems the easiest would be to not use the p4-$DateTime$ but generate new version strings from a script which also does the submit.

The script exists and will be called automatically every Monday at 5:00 Bremen time. Best regards Martin -- Martin Schröder, MS@ArtCom-GmbH.DE ArtCom GmbH, Grazer Straße 8, D-28359 Bremen Voice +49 421 20419-44 / Fax +49 421 20419-10