On 2013/04/25 03:10:59, Keith wrote:
LGTM, if you really think masking the stem is a reliable solution.
AAAAahhahhahahahahahahahaha. Of course I really don't think it a reliable solution. I mean, look at how ridiculous the code is: I am bending the mask away from the stroke wherever possible exactly because the set of previewers and renderers we are trying to placate is trying to sabotage the rendering in any imaginable and unimaginable way. The code is a piece of crock based on the principle "Anything that can go wrong, will. And then more.", and that's exactly what the previewers are doing here. I can totally and seriously improve the output for bitmap rendering from Ghostscript: in case we are doing _bitmaps_, I can do all sort of quantization tricks because then the device coordinate space is known. So far, the code does not make any use of device coordinates. And GSView would likely be able to use this sort of code. For PDF, this route is barred. https://codereview.appspot.com/8663044/diff/31002/ps/music-drawing-routines.ps
File ps/music-drawing-routines.ps (right):
https://codereview.appspot.com/8663044/diff/31002/ps/music-drawing-routines.ps#newcode107
ps/music-drawing-routines.ps:107: abs exch abs exch If you still have reliable notes on the stack layout, a comment or two
would be
very nice, especially here as we go into the nested ifs.
The stack layout is pretty much trivial throughout. At the beginning, width and height are made non-negative, the coordinate system is reset to make the inner box (sans linewidth) start at coordinates 0 0, and the stack layout is savedmatrix width height pretty much everywhere. The blot diameter is put into currentlinewidth pretty much at the start. Suggestions for a good comment? https://codereview.appspot.com/8663044/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel