Hi, I have just uploaded the archives for a new luatex release, 0.42.0. NOTE: This snapshot is just for testing the new sources and the updated build process, do NOT trust this binary for production work! There is a whole lot of work done on the luatex internals since the previous beta, and just judging by the amount of work done it seems likely that there will be a few serious bugs remaining. There are two big internal changes. Both changes are invisible to the user, but definately worth mentioning: * There is no pascal (web) code in luatex at all anymore, everything is now converted into plain C and split over about 50 source files. Later, this code will be converted back to CWEB (almost all comments have been kept) but first we want to spend a few months reorganizing the code base. * The PDF backend has been reorganized a lot, and most of the global variables are not put into a single backend structure. Work in this area is not complete, but getting there. The other newsworthy changes are: * There is a new node.tail() function * lua-loaded fonts now support a 'nomath' key to speed up loading the lua table. * A bugfix in the ttf reader for the inclusion backend, and (also in the backend) support for treating ttc files by pretending they are single ttf fonts (both patches from pdftex) * Add Khaled Hosny's man page to the repository * The \pdfcompresslevel is now effectively fixed as soon as output to the pdf file has occurred. * Patched status.filename so that it (nearly) always returns a file name. * fix '\the\delcode' and disable '\the\odelcode', '\the\Udelcode', and '\the\Udelcodenum' * Handle jfifs where either xres or yres is 0 and the other res is != 0 (from pdftex) * The single-argument version of lang.hyphenate() was broken. * Get rid of the \directlua/\latelua number warning. * The Lua coroutine patch (coco) is now disabled on linux powerpc architectures (because it caused crashes) * Removed obsolete pdftex primitives: \pdfoptionalwaysusepdfpagebox \pdfoptionpdfinclusionerrorlevel \pdfforcepagebox \pdfmovechars * The loading speed of large fonts (especially ttf) via the fontloader library, and the inclusion speed for subsetting in the backend have both been improved. * The 'pdf' lua library has been enhanced with various new functions, see the manual for details. * BLT and BRT glyph position fixed. * Various fixes for synctex offsets. * Support for exotic font string encodings has been removed from the fontloader library. * The embedded MPlib is now 1.205. * libpng is now 1.2.38. The archives can be downloaded from supelec as usual: http://foundry.supelec.fr/gf/project/luatex/ You could also check out the sources via anonymous svn: svn co http://foundry.supelec.fr/svn/luatex/tags/0.42.0 Bugs and feature requests can be added to the issue tracker at http://tracker.luatex.org Have fun, Taco
On Fri, Jul 17, 2009 at 12:31:56PM +0200, Taco Hoekwater wrote:
* The \pdfcompresslevel is now effectively fixed as soon as output to the pdf file has occurred.
Why? Is there a technical reason?
Sometimes it makes sense to have some parts uncompressed
(e.g. for debugging purposes, ...)
Yours sincerely
Heiko
Heiko Oberdiek wrote:
On Fri, Jul 17, 2009 at 12:31:56PM +0200, Taco Hoekwater wrote:
* The \pdfcompresslevel is now effectively fixed as soon as output to the pdf file has occurred.
Why? Is there a technical reason?
Yes (-ish). The compression level is now a part of the pdf back-end structure because with that, the back-end does not have to access eqtb all the time. It would be possible to do a synchronization whenever the value in eqtb changes, but:
Sometimes it makes sense to have some parts uncompressed (e.g. for debugging purposes, ...)
You could just be brave and not compress the pdf at all. Best wishes, Taco
Hello Taco, On Fri, Jul 17, 2009 at 01:18:41PM +0200, Taco Hoekwater wrote:
Heiko Oberdiek wrote:
On Fri, Jul 17, 2009 at 12:31:56PM +0200, Taco Hoekwater wrote:
* The \pdfcompresslevel is now effectively fixed as soon as output to the pdf file has occurred.
Why? Is there a technical reason?
Yes (-ish). The compression level is now a part of the pdf back-end structure because with that, the back-end does not have to access eqtb all the time. It would be possible to do a synchronization whenever the value in eqtb changes, but:
Sometimes it makes sense to have some parts uncompressed (e.g. for debugging purposes, ...)
You could just be brave and not compress the pdf at all.
There can be Metadata Streams in the PDF file (e.g. in the Catalog).
The PDF specification says in "10.2.2 Metadata Streams":
| The contents of a metadata stream is the metadata represented in
| Extensible Markup Language (XML). This information is visible as plain
| text to tools that are not PDF-aware only if the metadata stream is both
| unfiltered and unencrypted.
How can the compression of these streams can be avoided without
having umcompressed anything else?
Yours sincerely
Heiko
Hi, Heiko Oberdiek wrote:
There can be Metadata Streams in the PDF file (e.g. in the Catalog).
Ah, I didn't know that. The next release will restore the dynamicness of \pdfcompresslevel and \pdfobjcompresslevel. (the code is checked in already). Best wishes, Taco
On Fri, Jul 17, 2009 at 03:00:00PM +0200, Taco Hoekwater wrote:
Heiko Oberdiek wrote:
There can be Metadata Streams in the PDF file (e.g. in the Catalog).
Ah, I didn't know that. The next release will restore the dynamicness of \pdfcompresslevel and \pdfobjcompresslevel. (the code is checked in already).
Thanks.
Yours sincerely
Heiko
Hi!
* The \pdfcompresslevel is now effectively fixed as soon as output to the pdf file has occurred.
Why? Is there a technical reason?
Yes (-ish). The compression level is now a part of the pdf back-end structure because with that, the back-end does not have to access eqtb all the time.
Sometimes it makes sense to have some parts uncompressed (e.g. for debugging purposes, ...)
You could just be brave and not compress the pdf at all.
There can be Metadata Streams in the PDF file (e.g. in the Catalog). The PDF specification says in "10.2.2 Metadata Streams":
just a thought - if cleanup for making \pdfcompresslevel static makes the code simpler ("The compression level is now a part of the pdf back-end structure ..."), maybe there could be an option in the \pdfobj to force a particular stream to have no compression, instead of making \pdfcompresslevel dynamic? something like \pdfobj stream nocompress ... Best, v.
Vladimir Volovich wrote:
just a thought - if cleanup for making \pdfcompresslevel static makes the code simpler ("The compression level is now a part of the pdf back-end structure ..."), maybe there could be an option in the \pdfobj to force a particular stream to have no compression, instead of making \pdfcompresslevel dynamic?
something like \pdfobj stream nocompress ...
I am thinking of pushing a whatsit into the node stream to control such settings. That or your solution will become a requirement if we ever want to move the backend to a separate thread. Best wishes, Taco
Taco Hoekwater wrote:
Vladimir Volovich wrote:
just a thought - if cleanup for making \pdfcompresslevel static makes the code simpler ("The compression level is now a part of the pdf back-end structure ..."), maybe there could be an option in the \pdfobj to force a particular stream to have no compression, instead of making \pdfcompresslevel dynamic?
something like \pdfobj stream nocompress ...
I am thinking of pushing a whatsit into the node stream to control such settings. That or your solution will become a requirement if we ever want to move the backend to a separate thread.
but it will be a different primitive then as we don't want a such node in the document preamble Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
"TH" == Taco Hoekwater writes:
just a thought - if cleanup for making \pdfcompresslevel static makes the code simpler ("The compression level is now a part of the pdf back-end structure ..."), maybe there could be an option in the \pdfobj to force a particular stream to have no compression, instead of making \pdfcompresslevel dynamic?
something like \pdfobj stream nocompress ...
TH> I am thinking of pushing a whatsit into the node stream to control TH> such settings. That or your solution will become a requirement if TH> we ever want to move the backend to a separate thread. if the purpose to disable compression is for debugging, then your suggestion to "be brave and not compress the pdf at all" is the best solution. the rest of the need to prevent compression seems to be for specific streams such as metadata, where it is enough to use an option in the \pdfobj, instead of making a more complex approach with whatsit nodes. Best, v.
participants (4)
-
Hans Hagen -
Heiko Oberdiek -
Taco Hoekwater -
Vladimir Volovich