On Wed, Apr 8, 2009 at 12:40 PM, Mark Polesky wrote:
>> A significant reduction in actual code can be had with careful use of a
>> private dictionary, sometimes just using shorter names for common
>> operators can help a lot (eg, mt for moveto), but also creating new
>> operators for common opera
On Wed, Apr 8, 2009, Mark Polesky said:
Would reducing ps excess reduce compilation
> time? Or would the difference be negligible?
PS code is not usually compiled, it is transmitted, parsed, and executed.
Adobes manuals make it clear that the defined operators are deliberatly
given long spelle
Han-Wen Nienhuys wrote:
> The ly:format routine was created as a C++ one because we had
> significant memory blowup due to the use of format routines that ran
> in Scheme. You may want to submit a simple patch to make it strip
> trailing zeroes from decimals; then you get a simple reduction in f
On Tue, Apr 7, 2009, Mark Polesky said:
> Short version: I made some changes to output-ps.scm
> that can safely reduce the file size of ps files. In
> a simple experiment, I was able to reduce non-binary
> ps-code by up to 10%.
PS code is notorious for being voluminous. Most of the time the st
On Tue, Apr 7, 2009 at 9:25 PM, Mark Polesky wrote:
> Short version: I made some changes to output-ps.scm
> that can safely reduce the file size of ps files. In
> a simple experiment, I was able to reduce non-binary
> ps-code by up to 10%. I also don't know if anyone
> cares! (: See the attachment
By the way, something similar could be done
with framework-ps.scm, although you'd only
save something like 35 bytes of file size.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-d
Short version: I made some changes to output-ps.scm
that can safely reduce the file size of ps files. In
a simple experiment, I was able to reduce non-binary
ps-code by up to 10%. I also don't know if anyone
cares! (: See the attachment.
- Mark
Long version (sorry this is so long):
LilyPond gen
