[dev-context] format() without formatting

Peter Rolf peter.rolf at arcor.de
Tue Jun 17 16:29:09 CEST 2008


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
> -----------------------------------------------------------------
> 





More information about the dev-context mailing list