Re: Guidelines for bounding boxes?
I think that the two boxes 11 11 222++222 2 11 2 222++222 11 11 should suffice for most practical purposes... Maybe. This is something which should be tested as soon as someone is going to write support for it. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 14. August 2009 06:54:45 schrieb David Kastrup: Werner LEMBERG w...@gnu.org writes: FWIW, I used to think that this would be a very important feature; now I'm not so sure. There are certainly a few cases (eg. slurs, hairpins, treble clefs) where having more accurate outlines would help. It would also help in improved positioning of accidentals. But the list is fairly short: for most glyphs, a more accurate box wouldn't matter much. One character where I have run into problems because of a too large bbox is the f dynamics sign. The upper left corner is empty, yet the bounding box claims it as part of the f, so everything else will be positioned too far away if the right edge happens to overlap a little bit with the left edge of the f... Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKhVQUTqjEwhXvPN0RAsuYAKCxoZA/3UmmVrpyogqJpsCR3PJamACgmgG6 FKBQnAsD+O7mkn2j7xg9hyM= =qh0/ -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
2009/8/11 Mark Polesky markpole...@yahoo.com: Then I propose the following Dutch-English changes: Added as http://code.google.com/p/lilypond/issues/detail?id=830 (just in case we can't do it in a near future) Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
However, we need a mechanism to improve the more critical cases. Maybe attaching some ghost characters without actual content to the glyphs might be possible, where the total outline is determined by overlaying all the bounding boxes? This is a very nice idea! For example, the | | | _ |/ \ |__/ glyph could be composed of two glyphs: The first holds the complete shape but its metrics box only consists of the bowl. The second one is an empty box, firmly attached on the top, which exactly covers the stem: ++ || || ++-+ | | +--+ Some glyphs, however, like the `sharp' accidental, would need one main box and four attached ghost boxes: I fear that too many ghost boxes would dramatically increase the processing time of lilypond... If we ever are going to implement this (which I would welcome), we probably have to find a similar mechanism which has been optimized for speed. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Werner LEMBERG w...@gnu.org writes: However, we need a mechanism to improve the more critical cases. Maybe attaching some ghost characters without actual content to the glyphs might be possible, where the total outline is determined by overlaying all the bounding boxes? This is a very nice idea! For example, the | | | _ |/ \ |__/ glyph could be composed of two glyphs: The first holds the complete shape but its metrics box only consists of the bowl. The second one is an empty box, firmly attached on the top, which exactly covers the stem: ++ || || ++-+ | | +--+ Some glyphs, however, like the `sharp' accidental, would need one main box and four attached ghost boxes: I fear that too many ghost boxes would dramatically increase the processing time of lilypond... I think that the two boxes 11 11 222++222 2 11 2 222++222 11 11 should suffice for most practical purposes... -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
FWIW, I used to think that this would be a very important feature; now I'm not so sure. There are certainly a few cases (eg. slurs, hairpins, treble clefs) where having more accurate outlines would help. It would also help in improved positioning of accidentals. But the list is fairly short: for most glyphs, a more accurate box wouldn't matter much. I agree. However, we need a mechanism to improve the more critical cases. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Werner LEMBERG w...@gnu.org writes: FWIW, I used to think that this would be a very important feature; now I'm not so sure. There are certainly a few cases (eg. slurs, hairpins, treble clefs) where having more accurate outlines would help. It would also help in improved positioning of accidentals. But the list is fairly short: for most glyphs, a more accurate box wouldn't matter much. I agree. However, we need a mechanism to improve the more critical cases. Maybe attaching some ghost characters without actual content to the glyphs might be possible, where the total outline is determined by overlaying all the bounding boxes? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
So, if I am understanding correctly, LilyPond currently uses the same dimensions for both the metrics box and the bounding box for each glyph. This is why the longa glyph, for example, is cropped in the EPS/PNG output. Is this true? I think so. On the other hand, we need an exact bbox only for cropped images, right? ghostscript has a special output device called `bbox' which computes a precise bounding box for its input. Wouldn't it be thus sufficient to introduce an intermediate step during the EPS-PNG conversion to simply call this device? Another improvement would be to provide `shaped metrics': Currently, the metrics for a glyph consist of a single rectangle. This could be extended to a list of rectangles which are then merged. But would this help with collision handling? I was under the impression that the Stencil extents (which form a box) are used for collision handling (skylines, etc.). My idea is that a single grob can consist of multiple boxes, providing a more accurate skyline. For objects taken from the emmentaler font you only get a single rectangle currently, which is often only a very rough approximation of the real shape. Or is the glyph metrics information used instead of the Stencil extents? I don't know these details. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Mon, Aug 10, 2009 at 4:27 AM, Werner LEMBERGw...@gnu.org wrote: One has to keep in mind that Metafont does not permit more than 16 different heights per font (something like that, I don't remember the exact details). Yes, this problem already bites us. I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. It's basically a logistic change which can be done even with minimal knowledge of the Metafont language -- perhaps this is something for a frog? This is red herring. The metrics for feta are computed by parsing the metafont .log file. The .TFM files are unused, because of the limits on different sizes, and because it does not support no negative width. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Sun, Aug 9, 2009 at 9:44 PM, Patrick McCartypnor...@gmail.com wrote: Are there any guidelines LilyPond adheres to for creating bounding boxes? For example, when I adjusted the bbox for the \eyeglasses markup command, I _underestimated_ the bbox. Should I have slightly _overestimated_ instead? Attached is a PNG displaying the bbox. Also, in the case of Metafont glyphs, there doesn't appear to be a clear convention: some bounding boxes are underestimated, but others are overestimated. There is no strict convention. Some dimensions are used very specifically inside lilypond, so they should be exact (for example: note head dimensions); for others, the difference is unimportant: the bass clef is covered by the staff anyway, so the half-linethick error does not make a difference -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Han-Wen Nienhuys hanw...@gmail.com writes: On Mon, Aug 10, 2009 at 4:27 AM, Werner LEMBERGw...@gnu.org wrote: One has to keep in mind that Metafont does not permit more than 16 different heights per font (something like that, I don't remember the exact details). Yes, this problem already bites us. I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. It's basically a logistic change which can be done even with minimal knowledge of the Metafont language -- perhaps this is something for a frog? This is red herring. The metrics for feta are computed by parsing the metafont .log file. The .TFM files are unused, because of the limits on different sizes, and because it does not support no negative width. Oh. Any idea where to document this prominently enough that people stop worrying about it? If the TFM are really unused, then the font setup should likely include fontmaking := 0; after mode_setup. In that case, no TFM file is produced at all, probably reducing the possible confusion. With some luck, the warnings go away as well, but I have not tried this myself and am to lazy to check the metafont source. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. This is red herring. The metrics for feta are computed by parsing the metafont .log file. The .TFM files are unused, because of the limits on different sizes, and because it does not support no negative width. Aah, excellent. I wasn't aware of this. So please mark my request as invalid. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Han-Wen Nienhuys wrote: They were an in-crowd joke at some point, but I think the joke has lasted long enough. I approve of changes that bring regularity in this file naming scheme. Then I propose the following Dutch-English changes: feta-banier feta-flags feta-beugel feta-braces feta-bolletjes feta-noteheads feta-din-code feta-dynamics feta-eindelijk feta-rests feta-haak feta-brackettips feta-klef feta-clefs feta-nummer-codefeta-numbers feta-pendaalfeta-pedal feta-puntje feta-dots feta-schriftfeta-scripts feta-slag feta-trills feta-toevallig feta-accidentals I also propose changing the following for fet_begingroup symmetry: feta-arrow feta-arrowheads paremsan-heads parmesan-noteheads These two would remain unchanged: feta-accordion feta-accordion feta-timesigfeta-timesig Comments? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Tue, Aug 11, 2009 at 3:47 PM, Mark Poleskymarkpole...@yahoo.com wrote:
They were an in-crowd joke at some point, but I think the joke
has lasted long enough. I approve of changes that bring
regularity in this file naming scheme.
Then I propose the following Dutch-English changes:
feta-banier feta-flags
feta-beugel feta-braces
feta-bolletjes feta-noteheads
feta-din-code feta-dynamics
We had the -code files as a contrast to the feta-din{NUMBER}, which
included the -code ones.
feta-eindelijk feta-rests
feta-haak feta-brackettips
feta-klef feta-clefs
feta-nummer-code feta-numbers
feta-pendaal feta-pedal
be consistent with plural vs singular.
feta-puntje feta-dots
feta-schrift feta-scripts
feta-slag feta-trills
feta-toevallig feta-accidentals
I also propose changing the following for fet_begingroup symmetry:
feta-arrow feta-arrowheads
paremsan-heads parmesan-noteheads
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
feta-pendaalfeta-pedal Perhaps feta-pedalsigns? feta-accordion feta-accordion feta-accordionsigns? feta-timesigfeta-timesig feta-timesignatures? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
- Original Message
From: Han-Wen Nienhuys hanw...@gmail.com
To: Mark Polesky markpole...@yahoo.com
Cc: Werner LEMBERG w...@gnu.org; lilypond-devel@gnu.org
Sent: Tuesday, August 11, 2009 11:57:48 AM
Subject: Re: Guidelines for bounding boxes?
On Tue, Aug 11, 2009 at 3:47 PM, Mark Poleskywrote:
They were an in-crowd joke at some point, but I think the joke
has lasted long enough. I approve of changes that bring
regularity in this file naming scheme.
Then I propose the following Dutch-English changes:
feta-banier feta-flags
feta-beugel feta-braces
feta-bolletjes feta-noteheads
feta-din-code feta-dynamics
We had the -code files as a contrast to the feta-din{NUMBER}, which
included the -code ones.
Is there a problem with feta-dynamics? The last feta-din{NUMBER}
was removed 5 years ago:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=90fac
And feta-din was removed 4 years ago:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=c17ec
feta-eindelijk feta-rests
feta-haak feta-brackettips
feta-klef feta-clefs
feta-nummer-codefeta-numbers
feta-pendaalfeta-pedal
be consistent with plural vs singular.
I was just following the fet_begingroup strings.
Are you suggesting to change line 18 of feta-pendaal.mf from
fet_begingroup (pedal);
to
fet_begingroup (pedals);
?
I'm not opposed to it, but that would entail a lot of other
changes, too. And what about timesigs? accordions?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On 8/11/09 12:47 PM, Mark Polesky markpole...@yahoo.com wrote: Han-Wen Nienhuys wrote: They were an in-crowd joke at some point, but I think the joke has lasted long enough. I approve of changes that bring regularity in this file naming scheme. Then I propose the following Dutch-English changes: feta-banier feta-flags feta-beugel feta-braces feta-bolletjes feta-noteheads feta-din-code feta-dynamics feta-eindelijk feta-rests feta-haak feta-brackettips feta-klef feta-clefs feta-nummer-codefeta-numbers feta-pendaalfeta-pedal feta-puntje feta-dots feta-schriftfeta-scripts feta-slag feta-trills feta-toevallig feta-accidentals I also propose changing the following for fet_begingroup symmetry: feta-arrow feta-arrowheads paremsan-heads parmesan-noteheads These two would remain unchanged: feta-accordion feta-accordion feta-timesigfeta-timesig feta-timesig feta-timesignatures Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Mon, Aug 10, 2009 at 07:02:39AM +0200, Werner LEMBERG wrote: Also, in the case of Metafont glyphs, there doesn't appear to be a clear convention: some bounding boxes are underestimated, but others are overestimated. What you call `bounding boxes' aren't real bboxes but the metrics boxes of the glyphs. In case of the bass clef, for example, the top shape is treated as with many other rounded glyphs in normal fonts: The `overshoot' sticks out. On the other hand, the height has been enlarged so that it covers the staff vertically. Similar considerations hold for other glyphs. However, I don't object to revising the metrics since the dimensions of the glyphs stem from the time where the TeX engine has been used for layout. Most restrictions are probably no longer of importance. Okay, I see the difference now. Thanks for your explanation. So, if I am understanding correctly, LilyPond currently uses the same dimensions for both the metrics box and the bounding box for each glyph. This is why the longa glyph, for example, is cropped in the EPS/PNG output. Is this true? One issue remains: Should the metrics and the bbox differ at all? My opinion is yes, but this is something Joe can probably answer best. It sounds like they should differ, depending on the case, since the boxes deal with two different concepts. I've attached examples of various cases. The longa example uses the glyph noteheads.sM2neomensural. Perhaps we have to add new fields to the lilypond tables embedded into the OpenType fonts which gives real bounding boxes. Alternatively, we can use FontForge to compute them automatically. I think it would be a good idea to compute them with FontForge. Another improvement would be to provide `shaped metrics': Currently, the metrics for a glyph consist of a single rectangle. This could be extended to a list of rectangles which are then merged. For the longa glyph, this could be these two boxes: +-+ ++ +++ | | || ||| +-+ +||=+++ || || || || || || || || || || ++ ++ Doing so would allow much enhanced precision in collision handling. This is quite interesting. But would this help with collision handling? I was under the impression that the Stencil extents (which form a box) are used for collision handling (skylines, etc.). Or is the glyph metrics information used instead of the Stencil extents? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Tue, 2009-08-11 at 20:03 -0700, Patrick McCarty wrote: On Mon, Aug 10, 2009 at 07:02:39AM +0200, Werner LEMBERG wrote: Another improvement would be to provide `shaped metrics': Currently, the metrics for a glyph consist of a single rectangle. This could be extended to a list of rectangles which are then merged. For the longa glyph, this could be these two boxes: +-+ ++ +++ | | || ||| +-+ +||=+++ || || || || || || || || || || ++ ++ Doing so would allow much enhanced precision in collision handling. This is quite interesting. But would this help with collision handling? I was under the impression that the Stencil extents (which form a box) are used for collision handling (skylines, etc.). Or is the glyph metrics information used instead of the Stencil extents? The glyph metrics are used to compute the stencil extents. There is no particular reason, though, that we have to use a single box. Have a look at calc_skyline_spacing in axis-group-interface.cc. It uses boxes for most grobs, but more complicated outlines for others (ie. axis-groups). It could certainly be modified to use more complicated outlines for grobs that supported it. FWIW, I used to think that this would be a very important feature; now I'm not so sure. There are certainly a few cases (eg. slurs, hairpins, treble clefs) where having more accurate outlines would help. But the list is fairly short: for most glyphs, a more accurate box wouldn't matter much. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Werner LEMBERG w...@gnu.org writes: Are there any guidelines LilyPond adheres to for creating bounding boxes? No. For example, when I adjusted the bbox for the \eyeglasses markup command, I _underestimated_ the bbox. Should I have slightly _overestimated_ instead? Attached is a PNG displaying the bbox. I think overestimation is better. Also, in the case of Metafont glyphs, there doesn't appear to be a clear convention: some bounding boxes are underestimated, but others are overestimated. What you call `bounding boxes' aren't real bboxes but the metrics boxes of the glyphs. In case of the bass clef, for example, the top shape is treated as with many other rounded glyphs in normal fonts: The `overshoot' sticks out. On the other hand, the height has been enlarged so that it covers the staff vertically. One has to keep in mind that Metafont does not permit more than 16 different heights per font (something like that, I don't remember the exact details). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
One has to keep in mind that Metafont does not permit more than 16 different heights per font (something like that, I don't remember the exact details). Yes, this problem already bites us. I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. It's basically a logistic change which can be done even with minimal knowledge of the Metafont language -- perhaps this is something for a frog? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. It's basically a logistic change which can be done even with minimal knowledge of the Metafont language -- perhaps this is something for a frog? This is now issue #829. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Hi Werner, if you can explain me what should I do, I would try to make it. -- Marek Klein http://gregoriana.sk 2009/8/10 Werner LEMBERG w...@gnu.org I'll add a bug tracker item which suggests to split the Metafont output into even smaller units, say, 16 glyphs per subfont, to circumvent the problem. It's basically a logistic change which can be done even with minimal knowledge of the Metafont language -- perhaps this is something for a frog? This is now issue #829. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
if you can explain me what should I do, I would try to make it. OK. However, it seems to be more complicated than thougth at a first glance. Anyway, here a rough outline how it could be done. 1. Metafont is called for those fonts: feta11.mf, feta13.mf, ..., feta-braces-a.mf, feta-braces-b.mf, ..., feta-alphabet11.mf, feta-alphabet13.mf, ..., parmesan11.mf, parmesan13.mf, ... Except of the feta-alphabetXX fonts, all fonts cause warnings since they contain more than 15 different heights and depths. The idea is now to split up feta, feta-brace, and parmesan into smaller fonts. Let's look into feta11.mf: It reads feta-autometric for some macros, sets the design size, then reads the generic driver file feta-generic.mf. This file in turn reads the following files: feta-eindelijk feta-toevallig feta-arrow feta-puntje feta-bolletjes feta-schrift feta-banier feta-klef feta-timesig feta-pendaal feta-haak feta-accordion I could now imagine to replace feta11 with feta-eindelijk11, feta-toevallig11, feta-arrow11, ... Similar things should be done for the other sub-families. feta-eindelijk11.mf would look like this: input feta-autometric; design_size := 11.22; subfont := feta-eindelijk; input feta-generic; end. The `subfont' variable is then used in feta-generic; instead of the large number of `input ...' lines you would just have scantokens (input subfont); [`input' doesn't expand its argument; you have to use the above trick as explained in The METAFONT book, page 180.] 2. Update `aybabtu.pe.in'. 3. You have to update `scripts/build/mf-to-table.py' to add a new command line option so that all its arguments are recognized as subfonts, sending the output data to a single file instead of multiple files. 4. Update scripts/build/gen-emmentaler-scripts.py to load all subfonts. 5. Update GNUmakefile. To see what's going on I recommend that you compile lilypond from scratch, diverting stdin and stderr to a file like this: make all make.all.log A further refinement would be to make the Makefile generate the Metafont driver files on the fly to avoid zillions of input files. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Werner LEMBERG wrote: feta-eindelijk feta-toevallig feta-arrow feta-puntje feta-bolletjes feta-schrift feta-banier feta-klef feta-timesig feta-pendaal feta-haak feta-accordion I've always wished those were in English. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
feta-eindelijk feta-toevallig feta-arrow feta-puntje feta-bolletjes feta-schrift feta-banier feta-klef feta-timesig feta-pendaal feta-haak feta-accordion I've always wished those were in English. Well, it isn't. I think this is a good thing. Not everything in the world should be US-centric. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Werner LEMBERG wrote: I've always wished those were in English. Well, it isn't. I think this is a good thing. Not everything in the world should be US-centric. I wasn't meaning to sound US-centric; I'm more concerned with wasting developers' time with hard-to-read code. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
On Mon, Aug 10, 2009 at 5:57 PM, Mark Poleskymarkpole...@yahoo.com wrote: I've always wished those were in English. Well, it isn't. I think this is a good thing. Not everything in the world should be US-centric. I wasn't meaning to sound US-centric; I'm more concerned with wasting developers' time with hard-to-read code. They were an in-crowd joke at some point, but I think the joke has lasted long enough. I approve of changes that bring regularity in this file naming scheme. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Guidelines for bounding boxes?
Hi, Are there any guidelines LilyPond adheres to for creating bounding boxes? For example, when I adjusted the bbox for the \eyeglasses markup command, I _underestimated_ the bbox. Should I have slightly _overestimated_ instead? Attached is a PNG displaying the bbox. Also, in the case of Metafont glyphs, there doesn't appear to be a clear convention: some bounding boxes are underestimated, but others are overestimated. I've attached examples of various cases. The longa example uses the glyph noteheads.sM2neomensural. Thanks, Patrick attachment: eyeglasses-bbox.pngattachment: f-clef-bbox.pngattachment: longa-bbox.pngattachment: period-bbox.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Guidelines for bounding boxes?
Are there any guidelines LilyPond adheres to for creating bounding boxes? No. For example, when I adjusted the bbox for the \eyeglasses markup command, I _underestimated_ the bbox. Should I have slightly _overestimated_ instead? Attached is a PNG displaying the bbox. I think overestimation is better. Also, in the case of Metafont glyphs, there doesn't appear to be a clear convention: some bounding boxes are underestimated, but others are overestimated. What you call `bounding boxes' aren't real bboxes but the metrics boxes of the glyphs. In case of the bass clef, for example, the top shape is treated as with many other rounded glyphs in normal fonts: The `overshoot' sticks out. On the other hand, the height has been enlarged so that it covers the staff vertically. Similar considerations hold for other glyphs. However, I don't object to revising the metrics since the dimensions of the glyphs stem from the time where the TeX engine has been used for layout. Most restrictions are probably no longer of importance. One issue remains: Should the metrics and the bbox differ at all? My opinion is yes, but this is something Joe can probably answer best. I've attached examples of various cases. The longa example uses the glyph noteheads.sM2neomensural. Perhaps we have to add new fields to the lilypond tables embedded into the OpenType fonts which gives real bounding boxes. Alternatively, we can use FontForge to compute them automatically. Another improvement would be to provide `shaped metrics': Currently, the metrics for a glyph consist of a single rectangle. This could be extended to a list of rectangles which are then merged. For the longa glyph, this could be these two boxes: +-+ ++ +++ | | || ||| +-+ +||=+++ || || || || || || || || || || ++ ++ Doing so would allow much enhanced precision in collision handling. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
