Re: Optical size information in Emmentaler-nn OpenType fonts
Hi Werner, thanks for the thoughts Am 08.09.2012 08:47, schrieb Werner LEMBERG: I have an Adobe OpenType font family containing its font faces in four sets: text, caption, subhead and display, each set designed for use at different point sizes. I assume the different Emmentaler-nn fonts serve the same purpose. Sort of, yes. If I use this Adobe font with LaTeX and fontspec it selects the right font automatically depending on the point size. [...] I opened both fonts with FontForge but didn't find a setting that seems responsible, and I don't really know anything about the inner workings of OpenType (or any) font technologies. Aah. Look up the `size' feature on this page: http://www.microsoft.com/typography/otspec/features_pt.htm I wasn't aware that such a feature exists. The necessary information could be rather easily added using FontForge, I think. Your request definitely deserves a new issue in our tracker. :-) Would it make sense to add this? Yes. Unfortunately, it seems that Pango doesn't support this currently out of the box (I've just asked on the gtk-i18n-list to be sure) which means that lilypond doesn't directly benefit. Well, I'm not sure about that anymore. The feature makes sense if you have several variants of the same family, and these variants are designed to be used at different point sizes. What I'm now starting to doubt is that you can have this relation between font version and point size in our case. Which one would be the suitable Emmentaler version for a particular point size (in continuous text of another font)? I don't think there is a useful relation. For my purpose (embedding Emmentaler in continuous LaTeX text) it seems to make more sense to conceive the different .otf versions as 'weights' that could be made selectable (maybe s.th. like 1 through 7, corresponding to Emmentaler-26 to 11). This will be implemented either as an option for the commands or as a command to change weight somewhere in the document. So please excuse the noise. Best Urs Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Optical size information in Emmentaler-nn OpenType fonts
[...] it seems that Pango doesn't support this currently out of the box which means that lilypond doesn't directly benefit. Well, I'm not sure about that anymore. The feature makes sense if you have several variants of the same family, and these variants are designed to be used at different point sizes. This is exactly the case with the Emmentaler fonts. What I'm now starting to doubt is that you can have this relation between font version and point size in our case. Which one would be the suitable Emmentaler version for a particular point size (in continuous text of another font)? I don't think there is a useful relation. There are two issues: (1) The Emmentaler fonts provide optical sizes. A mechanism to automatically select the right font can be implemented using the `size' feature. (2) The relation between a text size and the Emmentaler size. I fully agree that it is not possible to define this one to one. However, you have exactly the same problem even with different text fonts. In other words, the Emmentaler fonts must be scaled in relation to the text font. For my purpose (embedding Emmentaler in continuous LaTeX text) it seems to make more sense to conceive the different .otf versions as 'weights' that could be made selectable (maybe s.th. like 1 through 7, corresponding to Emmentaler-26 to 11). This will be implemented either as an option for the commands or as a command to change weight somewhere in the document. I think this is the wrong concept because it mixes up (1) and (2). Just think of combining, say, Computer Modern Roman with Times Roman. You aren't going to assign `weights' to cmr, are you? Werner ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: NR-4.1.6. automatic saving of line breaking configuration
Le 11/09/2012 00:29, Trevor Daniels disait : Jean-Charles Malahieude wrote Monday, September 10, 2012 6:57 PM The last paragraph of the line breaking section (l. 1460 of spacing.itely) (which gets a @c TODO check this) puts me into trouble. I think it should be deleted (I've already @ignored it in French): Yes, it should be deleted. The section on two-pass spacing was deleted in 81f5263fa1b6adf642b06970cd34e10d4635495d 2009-08-23 Remove two-pass spacing code and documentation. but this paragraph seems to have been missed. May I remove it directly? Cheers, Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Clef transparent does not hide clefOctavation
I'm not top posting (I don't know what that is!)
the override Clef transparent tag does not get rid of the 8 on octava clefs.
If there's another way to do it, I haven't seen it and it'd be great to
document.
Thanks for the amazing work! We've just got MusicXML ossias to Lilypond almost
100% working thanks to the great docs.
Best, Myke Cuthbert (cuthb...@mit.edu)
### begin snippet #
\version 2.16.0
\new Staff = testStaff
\with {
\override Clef #'transparent = ##t
}
{ \clef treble_8 c4 }
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Chordname collisions
Hello, 2012/9/9 Jim Long lilyp...@umpquanet.com I'm having the problem illustrated in the attachment, the collision of the markup for the second and third chords in the ChordNames staff. If this is a bug, is there a simple workaround I can use until the collision issue is addressed? Thank you for the report, I have added a new comment to the issue 1700: http://code.google.com/p/lilypond/issues/detail?id=1700 Marek bug squad member ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Clef transparent does not hide clefOctavation
2012/9/12 Michael Scott Cuthbert cuthb...@mit.edu:
I'm not top posting (I don't know what that is!)
the override Clef transparent tag does not get rid of the 8 on octava clefs.
If there's another way to do it, I haven't seen it and it'd be great to
document.
Thanks for the amazing work! We've just got MusicXML ossias to Lilypond almost
100% working thanks to the great docs.
Best, Myke Cuthbert (cuthb...@mit.edu)
### begin snippet #
\version 2.16.0
\new Staff = testStaff
\with {
\override Clef #'transparent = ##t
}
{ \clef treble_8 c4 }
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
The 8 is another grob, so ofcourse same behaviour in 2.12.3 and 2.14.2
Try:
\new Staff = testStaff
\with {
\override OctavateEight #'transparent = ##t
\override Clef #'transparent = ##t
}
{ \clef treble_8 c4 }
Best,
Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Clef transparent does not hide clefOctavation
Hello, 2012/9/12 Michael Scott Cuthbert cuthb...@mit.edu the override Clef transparent tag does not get rid of the 8 on octava clefs. If there's another way to do it, I haven't seen it and it'd be great to document. Thank you for the report, I have added it as http://code.google.com/p/lilypond/issues/detail?id=2832 Marek bug squad member ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
