Hans Hagen schrieb:
Peter Rolf wrote:
just looked deeper in mlib-pdf.lua. i simply added '%.3f' on all positions, where coordinates/measures are written. same for integer ('%.0f' or as in the pdf reference '%.1f'). much shorter and better
integers are %i and floats %f (which defaults to %.6f)
we really need at least 6 digits precision with graphics; for colors 3 digits is ok
you really need a precision of a millonth part of a point? or do you need it in combination with other units (cm,m)? me no pdf expert. anyhow, my graphics look similar with only three points after the digit. saves me another 5% in the compressed pdf.
readability of the unpacked pdf. so there is no really need for an *optimal* solution with an adapted format function. sorry for the noise.
With enabled compression things don't look that bad (regarding to file size), but it's still a unnecessary waste. indeed, such sequences compress well
yes <sigh>. i optimized some code and saved around 18k in the final uncompressed pdf (3% smaller). took me some time and i was a little proud of myself. after compressing all saving that was left were 1.111 bytes. <sigh again> :)
so your document is 99% graphics then?
yes. only some text in the graphic. people don't like to read much text in a gui :)
actually there are a few other optimizations i want to do (cm and such) but this is also related to literal processing in general (i need that for runtime generated fonts because (esp when we randomize too) one easilly get megs of inline fontdata
but this is not only a file size issue. you have to represent the data in some way in memory. less memory usage, less time for data scanning means faster viewing.
neglectable i guess, dealing with color spaces and such takes way more runtime
adding special formatter function has a low priority .. maybe some day
Hans
so can you please simply limit the number of digits after the point in mlib-pdf.lua? you have already done this for colors at the end of the source. if i have to patch one more file, i can make my own distribution ;)
i'm not going to change this so i fear that you will end up with your own low-res version
ok, it can't be helped. so it's one more file to patch. anyhow thanks to you and Arthur for your answers. i'm still trying to understand lpeg (once started, but never used it), so this is quite interesting stuff. regards, peter
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 -----------------------------------------------------------------