Re: More improvements to PostScript backend
David Feuer wrote: In my nonexistent free time I've done some more work. I'd really like to do something about the compulsive gsave x y translate 0 0 moveto grestore wrapping that everything gets. Could someone give me an idea of what could get stuffed into placebox? Is there actually some kind of global graphics state that we need to maintain as a default? It looks like pretty much everything sets all the variables it cares about. I'd like to change all the drawing procedures to draw at the current point. If they want to translate to make their lives easier they should clean up after themselves. Sounds good. Then the box wrapper becomes simply x y moveto, and we don't have to waste our time pushing and popping graphics states for no reason. By the way, in the future, should I include patches inline or attach them? This time I did both. The attached one is less likely to have line wrapping problems. This patch is against the versions in CVS. Your patch looks fine, but can you make a proper changelog entry (see eg. http://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs You can put the log in the entry of the email. If you use emacs, just press C-x 4 a to add it. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More improvements to PostScript backend
David Feuer schreef: of what could get stuffed into placebox? Is there actually some kind of global graphics state that we need to maintain as a default? It I think that color might be, but I'm not sure. should I include patches inline or attach them? This time I did both. The attached one is less likely to have line wrapping problems. This patch is against the versions in CVS. attachment is fine. Changelog: I'll have a better look at your patch over tomorrow, but I have one request: can you follow the ChangeLog format _exactly_ ? -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More improvements to PostScript backend
+% it's possible to eliminate the coordinate variables by doing [ /Rect [ 7 3 +% roll It is, however, kind of ugly. Another possibility, probably better, is +% to put the [ and ] into the other side, so this procedure will take an array. +% Yet another is to make pdfmark take its coordinates on the stack. I realized it would actually be very silly to put [ and ] at the calling site. That'll create a bunch of arrays for no reason that will have to be GCed later. Where is pdfmark defined, when it is defined? David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More improvements to PostScript backend
Would it be possible to put mark_URI wherever pdfmark is defined? That way, it won't be in the output unless it's actually used. Could someone give me a clue about stencils and grobs? My vague general impression is that it would probably be a big win for code maintenance, output quality, and output flexibility if the backend code did all the stencil interpretation, rather than having a separate stencil interpreter blindly paste together bits of PS or SVG. I don't know SVG, but the PostScript backend could certainly benefit from more information. The biggest wins would probably come from drawing all the noteheads and accidentals at once (or perhaps even just using a special procedure to draw noteheads, which can keep track of the notehead font), linking noteheads to stems, and keeping track of the stem width. It'd also be cool if PostScript knew about staves, and drew all the lines of the staff and all the clefs at once. You get the idea. David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More improvements to PostScript backend
Grr I forgot to delete the euclidean_length procedure from music-drawing-routines.ps. It is no longer used. David ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More improvements to PostScript backend
David Feuer schreef: Would it be possible to put mark_URI wherever pdfmark is defined? That way, it won't be in the output unless it's actually used. no. pdfmark is a routine that GS/Acrobat distiller provides to create URLs in the PDF output. It's defined in case the PS interpreter (say, one embedded in a printer) doesn't know about PDF. Could someone give me a clue about stencils and grobs? My vague general impression is that it would probably be a big win for code maintenance, output quality, and output flexibility if the backend code did all the stencil interpretation, rather than having a separate stencil interpreter blindly paste together bits of PS or SVG. I don't know SVG, but the PostScript backend could certainly benefit from more information. The biggest wins would probably come from drawing all the noteheads and accidentals at once (or perhaps even just using a special procedure to draw noteheads, which can keep track of the notehead font), linking noteheads to stems, and keeping track of the stem width. It'd also be cool if PostScript knew about staves, and drew all the lines of the staff and all the clefs at once. You get the idea. Yes, I get the idea, but I don't get the actual way you'd make this work, and -more importantly- why you would bother; editing lilypond output by hand is a very bad idea, IMO. Regarding stencils, see stencil.hh; it is a compositional method of dealing with graphics. Re: grobs http://lists.gnu.org/archive/html/lilypond-devel/2004-10/msg00241.html ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: More improvements to PostScript backend
When might I expect feedback on the new patch? David Feuer ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
