Re: 1/8 and 1/16 feta flags too wide?

> I've now set up a little comparison test (see attachment). [...] Great! While the effect is subtle, it can sum up significantly for longer pieces. > After all, I agree to go for unified widths because there is no > reason at all why tails of quavers/semiquavers should be treated >

Re: add glyphs for 256th, 512th and 1024th flags and rests (issue 336590043 by lilyp...@maltemeyn.de)

On 2018/02/23 11:41:13, Malte Meyn wrote: Probably that won’t be enough, it has to be 7,8 → 4 and 9,10 → 5; but the idea is correct. Maybe I’ll replace the cond by an if and case ;) Ah, yes, it's true that the rest height is identical for 128th/256th and 512th/1024th, therefore my

Re: 1/8 and 1/16 feta flags too wide?

>> While checking Malte's feta flag patches I've just seen that the >> 1/8 and 1/16 up-flags (i.e., glyphs `flags.u3' and `flags.u4') have >> a width approx. 10% larger than other `flags.uX' glyphs – this is >> also reflected in the lilypond metrics embedded in the fonts. Note >> that the two

Re: 1/8 and 1/16 feta flags too wide?

Werner LEMBERG wrote > Malte (or Thorsten), can you check whether formatting of 1/8 and 1/16 > flags improves if the width is harmonized with the other flags? I've now remove the extra stemthickness# / 2 from the 8th and 16th flags and run a regtest. There were no effects to be seen at all. So

Re: 1/8 and 1/16 feta flags too wide?

> I've now remove the extra stemthickness# / 2 from the 8th and 16th > flags and run a regtest. > > There were no effects to be seen at all. Thanks! > But for the sake of consistency and homogeneity, we (i.e. Malte) > should remove these two relics now we have issue #5277. Yes, this is a good

Re: 1/8 and 1/16 feta flags too wide?

Hi Werner, I've now set up a little comparison test (see attachment). On the left, you can see three flags (8th, 16th and 32th) with a tight surrounding box in a markup \column so that the slight differences in width are clearly visible. On the right, there is one bar of quavers with alternating

Re: add glyphs for 256th, 512th and 1024th flags and rests (issue 336590043 by lilyp...@maltemeyn.de)

On 2018/02/23 07:30:00, lemzwerg wrote: LGTM, thanks! In my opinion, there's a misplacement of rest dots. Therefore, file scm/output-lib.scm (dots::calc-staff-position) will have to be adapted, too (see related image and comment in issue #5277) There's no appropriate code for log > 7 (the

Re: add glyphs for 256th, 512th and 1024th flags and rests (issue 336590043 by lilyp...@maltemeyn.de)

On 2018/02/23 11:18:38, Be-3 wrote: On 2018/02/23 07:30:00, lemzwerg wrote: > LGTM, thanks! In my opinion, there's a misplacement of rest dots. Therefore, file scm/output-lib.scm (dots::calc-staff-position) will have to be adapted, too (see related image and comment in issue #5277)

Re: add glyphs for 256th, 512th and 1024th flags and rests (issue 336590043 by lilyp...@maltemeyn.de)

On 2018/02/23 11:18:38, Be-3 wrote: On 2018/02/23 07:30:00, lemzwerg wrote: > LGTM, thanks! In my opinion, there's a misplacement of rest dots. Therefore, file scm/output-lib.scm (dots::calc-staff-position) will have to be adapted, too (see related image and comment in issue #5277)

Re: 1/8 and 1/16 feta flags too wide?

Werner LEMBERG writes: > While checking Malte's feta flag patches I've just seen that the 1/8 > and 1/16 up-flags (i.e., glyphs `flags.u3' and `flags.u4') have a > width approx. 10% larger than other `flags.uX' glyphs – this is also > reflected in the lilypond metrics embedded in

Re: 1/8 and 1/16 feta flags too wide?

Hi Werner, As I see it, the character width (width of bounding box) of u* flags differs by half the stem thickness: width of flags.u3 and u4: hip_width# + *stemthickness# / 2* + right_upflag_space# width of flags.u5, u6, u7, etc.: hip_width# + right_upflag_space# This looks like an

Re: add glyphs for 256th, 512th and 1024th flags and rests (issue 336590043 by lilyp...@maltemeyn.de)

On 2018/02/23 12:09:34, pkx166h wrote: Are we simply seeing another symptom of something I (when patch testing) have to now ignore? See the thread: https://lists.gnu.org/archive/html/lilypond-devel/2017-09/msg00013.html No. But I’ll put this patch on needs_work now because it does need