----- Original Message -----
From: <lemzw...@googlemail.com>
To: <philehol...@googlemail.com>; <w...@gnu.org>; <gra...@percival-music.ca>;
<m...@philholmes.net>; <em...@philholmes.net>
Cc: <lilypond-devel@gnu.org>; <re...@codereview-hr.appspotmail.com>
Sent: Monday, September 24, 2012 6:34 PM
Subject: Re: Fixes position of mensural c clef (issue 6503091)
The glyph shape is OK, thanks. Have you tested the appearance on paper
of all available sizes, using a 300 or 600dpi printer?
No. Does this often come out strange? When you say "paper of all available
sizes" I don't understand why changing the paper size should have any
effect. Could you explain?
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (left):
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-clefs.mf#oldcode902
mf/parmesan-clefs.mf:902:
The dimension of the bounding box is not correct. It's far too large,
as can be seen in the DVI proof.
I was initially aware of this, but then forgot. Is there guidance on the the
correct way to calculate the parameters to set_char_box()?
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-clefs.mf
File mf/parmesan-clefs.mf (right):
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-clefs.mf#newcode791
mf/parmesan-clefs.mf:791: ..z2+(0, blot_rad)
This must be `.. {up}z2 + (0, blot_rad)', otherwise the curve doesn't
start with the right direction. This wouldn't be that bad, but it were
different to all other glyph shapes.
Ditto for all other transitions from `--' to `..' (this is, using the
proper `{up}', `{right}', etc.).
Excellent. I was aware of the discountinuity, but not the bext way to fix
it.
http://codereview.appspot.com/6503091/diff/16001/mf/parmesan-clefs.mf#newcode793
mf/parmesan-clefs.mf:793: --quartercircle scaled blot_diameter rotated
180 shifted (z3r + (blot_rad, blot_rad))
Using `quartercircle' gives good results in the type1 output. I only
ask you to make the line fit into 80 columns :-)
OK. I really should tell you to get a bigger monitor :-)
On the other hand, why not simply using something like
startcurve_point{down} .. {right}endcurve_point
? This might be shorter, and easier to read.
Didn't think of this as an option. The benefit of quartercurve is that it
takes the place of 2 points, so is actually shorter. I'd like to stick with
what I now have, but will remember this for the future.
http://codereview.appspot.com/6503091/
--
Phil Holmes
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
