Re: parameters in metafont files
2011/6/11 Carl Sorensen c_soren...@byu.edu: On 6/10/11 2:53 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: You are a GENIOUS!! I'm sure that genius is too strong a word to apply to me, but thanks for the kind words. You ressurrected an issue that, after 4 months of very slow development, was dead for 1 month. In other words, you gave me motivation to restart my work when i was too frustrated with 4 months of struggling to do anything for a whole month. And you *are* keeping me motivated by helping me with problems that arise. You *must* be genious if you did that. Thanks again! Even a blind squirrel finds a nut every once in a while. But not many squirrels find a truck of peanut butter :) thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
2011/6/10 Carl Sorensen c_soren...@byu.edu: On 6/9/11 3:18 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: I remember that i tried doing this separation, but something didn't work. I hope i have that draft somewhere though. I think that what causes problems is you lose the definition of black-notehead-width (which comes from feta-noteheads). Yes. I discovered that my previous try is available as Rietveld issue: http://codereview.appspot.com/4273119/ Unfortunately i still don't know how to extract the information about black_notehead_width. It should be made some kind of a global variable, but the main problem is that its value is not specified explicitely, but it's a result of a drawing operation. I searched for metafont resources on the web, but they seem to be very limited. I found http://metafont.tutorial.free.fr/, but it's about drawing operations, not structural problems. There also seems to be no active forum about it... Han-Wen, Werner, Keith, Marc - IIRC you are the people who work with fonts. Do you know how to do this and if it's possible at all? Otherwise i'll simply hardcode the value, but it'll be very rude (and a little wrong in fact - feta26 notehead width is 1.316 while feta11 notehead width is 1.306). Glad to be of help! I really do like your work, and I want to see it implemented in LilyPond. I'm so happy to hear this! Sometimes i have the impression that noone really cares. And wait till i start another project! It's gonna be about ties ;) Maybe i'll finish it before Lily 3.0... Great! I was sarcastic ;) in fact i want to do it in 1-2 months; some help from development team will be necessary for this ofc. Now i know that i cannot work longer than 2 months on a project, i'm going nuts after that time. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/10/11 5:43 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/6/10 Carl Sorensen c_soren...@byu.edu: On 6/9/11 3:18 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: I remember that i tried doing this separation, but something didn't work. I hope i have that draft somewhere though. I think that what causes problems is you lose the definition of black-notehead-width (which comes from feta-noteheads). Yes. I discovered that my previous try is available as Rietveld issue: http://codereview.appspot.com/4273119/ Unfortunately i still don't know how to extract the information about black_notehead_width. It should be made some kind of a global variable, but the main problem is that its value is not specified explicitely, but it's a result of a drawing operation. I've looked at this some more. In feta-noteheads.mf, line 39, we do save black_notehead_width which establishes black_notehead_width as a local variable to the group. It may be as simple as eliminating the save statement for black_notehead_width. Alternatively, it may involve expanding the group, instead. But I haven't worked that out yet. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
Oops, forgot to cc to the list... 2011/6/10 Janek Warchoł lemniskata.bernoull...@gmail.com: 2011/6/10 Marc Hohl m...@hohlart.de Am 10.06.2011 13:43, schrieb Janek Warchoł: [...] Unfortunately i still don't know how to extract the information about black_notehead_width. It should be made some kind of a global variable, but the main problem is that its value is not specified explicitely, but it's a result of a drawing operation. I searched for metafont resources on the web, but they seem to be very limited. I found http://metafont.tutorial.free.fr/, but it's about drawing operations, not structural problems. There also seems to be no active forum about it... Han-Wen, Werner, Keith, Marc - IIRC you are the people who work with fonts. Do you know how to do this and if it's possible at all? Perhaps my answer is too simple, but mf/feta-generic.mf says: %% this is a fallback so we can run the font without including feta-noteheads. black_notehead_width# := 1.0 staff_space#; and the same holds for mf/feta-noteheads-generic.mf. Does that work for you? Nope. This is only a dummy value, put there so that other functions using black_notehead_width don't complain. When compiled with this value, the result is squished flags: http://imageshack.us/photo/my-images/829/screenshotpxx.png/ Of course i can write a more appropriate value there (notehead is approximately 1.315 ss wide), but such hardcoding is bad. thanks, Janek PS perhaps it would be a good idea to write in the comment that this is a dummy value. I was fooled by it like you at the beginning :) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
Carl, 2011/6/10 Carl Sorensen c_soren...@byu.edu: On 6/10/11 5:43 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Unfortunately i still don't know how to extract the information about black_notehead_width. It should be made some kind of a global variable, but the main problem is that its value is not specified explicitely, but it's a result of a drawing operation. I've looked at this some more. In feta-noteheads.mf, line 39, we do save black_notehead_width which establishes black_notehead_width as a local variable to the group. It may be as simple as eliminating the save statement for black_notehead_width. it works! You are a GENIOUS!! I would never think about doing what you suggested. I'll update Rietveld issue; i also attach a patch if anyone wants to test it. I'll be working all day tomorrow, but i hope to write a first draft of feta-flags-autometric on Sunday. thanks! Janek From c02ea4247918fd7e220df618674c3c0d24553c50 Mon Sep 17 00:00:00 2001 From: Janek Warchol lemniskata.bernoull...@gmail.com Date: Fri, 10 Jun 2011 22:43:29 +0200 Subject: [PATCH] separating flags from noteheads until now, feta-noteheads contained both flag glyphs and notehead glyphs. This patch separates them - new family of feta-flags files is created. --- mf/GNUmakefile | 10 ++ mf/bigcheese.pe.in |1 + mf/feta-flags-generic.mf| 52 +++ mf/feta-flags11.mf | 13 mf/feta-flags13.mf | 13 mf/feta-flags14.mf | 13 mf/feta-flags16.mf | 13 mf/feta-flags18.mf | 13 mf/feta-flags20.mf | 13 mf/feta-flags23.mf | 13 mf/feta-flags26.mf | 13 mf/feta-noteheads-generic.mf|7 +--- mf/feta-noteheads-test-generic.mf |7 mf/feta-noteheads.mf|2 +- scripts/build/gen-emmentaler-scripts.py |1 + scripts/build/mf-to-table.py|2 + 16 files changed, 172 insertions(+), 14 deletions(-) create mode 100644 mf/feta-flags-generic.mf create mode 100644 mf/feta-flags11.mf create mode 100644 mf/feta-flags13.mf create mode 100644 mf/feta-flags14.mf create mode 100644 mf/feta-flags16.mf create mode 100644 mf/feta-flags18.mf create mode 100644 mf/feta-flags20.mf create mode 100644 mf/feta-flags23.mf create mode 100644 mf/feta-flags26.mf delete mode 100644 mf/feta-noteheads-test-generic.mf diff --git a/mf/GNUmakefile b/mf/GNUmakefile index c47b269..90cbd77 100644 --- a/mf/GNUmakefile +++ b/mf/GNUmakefile @@ -65,6 +65,7 @@ $(outdir)/emmentaler-%.otf\ $(outdir)/emmentaler-%.woff: $(outdir)/emmentaler-%.pe \ $(outdir)/feta%.pfb \ $(outdir)/feta-noteheads%.pfb \ + $(outdir)/feta-flags%.pfb \ $(outdir)/feta-alphabet%.pfb \ $(outdir)/parmesan%.pfb \ $(outdir)/feta%.otf-table \ @@ -83,40 +84,49 @@ $(outdir)/%.pfb: $(outdir)/%.log $(outdir)/%.otf-table: $(outdir)/%.lisp cat $ $(if $(findstring brace,$),,$(subst feta,parmesan,$)) \ $(if $(findstring brace,$),,$(subst feta,feta-noteheads,$)) \ + $(if $(findstring brace,$),,$(subst feta,feta-flags,$)) \ $(if $(findstring brace,$),,$(subst feta,feta-alphabet,$)) $@ ## ugh -- we want this to prevent failing -j2 compiles. $(outdir)/feta26.otf-table: $(outdir)/feta26.lisp \ $(outdir)/feta-noteheads26.lisp \ + $(outdir)/feta-flags26.lisp \ $(outdir)/parmesan26.lisp \ $(outdir)/feta-alphabet26.lisp $(outdir)/feta23.otf-table: $(outdir)/feta23.lisp \ $(outdir)/feta-noteheads23.lisp \ + $(outdir)/feta-flags23.lisp \ $(outdir)/parmesan23.lisp \ $(outdir)/feta-alphabet23.lisp $(outdir)/feta20.otf-table: $(outdir)/feta20.lisp \ $(outdir)/feta-noteheads20.lisp \ + $(outdir)/feta-flags20.lisp \ $(outdir)/parmesan20.lisp \ $(outdir)/feta-alphabet20.lisp $(outdir)/feta18.otf-table: $(outdir)/feta18.lisp \ $(outdir)/feta-noteheads18.lisp \ + $(outdir)/feta-flags18.lisp \ $(outdir)/parmesan18.lisp \ $(outdir)/feta-alphabet18.lisp $(outdir)/feta16.otf-table: $(outdir)/feta16.lisp \ $(outdir)/feta-noteheads16.lisp \ + $(outdir)/feta-flags16.lisp \ $(outdir)/parmesan16.lisp \ $(outdir)/feta-alphabet16.lisp $(outdir)/feta14.otf-table: $(outdir)/feta14.lisp \ $(outdir)/feta-noteheads14.lisp \ + $(outdir)/feta-flags14.lisp \ $(outdir)/parmesan14.lisp \ $(outdir)/feta-alphabet14.lisp $(outdir)/feta13.otf-table: $(outdir)/feta13.lisp \ $(outdir)/feta-noteheads13.lisp \ + $(outdir)/feta-flags13.lisp \ $(outdir)/parmesan13.lisp \ $(outdir)/feta-alphabet13.lisp
Re: parameters in metafont files
On 6/10/11 2:53 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Carl, 2011/6/10 Carl Sorensen c_soren...@byu.edu: It may be as simple as eliminating the save statement for black_notehead_width. it works! You are a GENIOUS!! I'm sure that genius is too strong a word to apply to me, but thanks for the kind words. Even a blind squirrel finds a nut every once in a while. I'm glad it worked for you! I've looked at your Rietveld patch, but I won't be able to actually test it until sometime later, but it may be a few days. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
Hi, i wanted to reply yesterday, but my dad broke our internet connection :) W dniu 8 czerwca 2011 00:05 użytkownik Carl Sorensen c_soren...@byu.edu napisał: On 6/1/11 9:39 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: (...) and have it output a flags.otf-table file looking like this (flags . (u . ((3 . (arbitraryRealValueChosenByMe)) (4 . (anotherArbitraryRealValueChosenByMe)) [...] )) . (d . [...] ))) Please help! After looking more at this, it appears that the .otf-table files are created by parsing the log files created during font creation. See scripts/build/mf-to-table.py So this means that your magic command would need to emit a keyword and a real value to the log file, and mf-to-table.py would need to be modified to read the keyword and the value and put it in the table file. Carl, you are great! After struggling with this shortened-flags issue for 5 months, i wouldn't have enough motivation to continue my work without your help! Right now I'm reading all the stuff that i did to remind myself where i am. As for now it looks that you are pointing me in the right direction! Thanks!! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/9/11 9:02 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi, i wanted to reply yesterday, but my dad broke our internet connection :) Unfortunately, I don't have anybody else to blame when my internet connection is broken. After looking more at this, it appears that the .otf-table files are created by parsing the log files created during font creation. See scripts/build/mf-to-table.py So this means that your magic command would need to emit a keyword and a real value to the log file, and mf-to-table.py would need to be modified to read the keyword and the value and put it in the table file. Carl, you are great! After struggling with this shortened-flags issue for 5 months, i wouldn't have enough motivation to continue my work without your help! Right now I'm reading all the stuff that i did to remind myself where i am. As for now it looks that you are pointing me in the right direction! Glad to be of help! I really do like your work, and I want to see it implemented in LilyPond. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
2011/6/8-9 Carl Sorensen c_soren...@byu.edu: After looking more at this, it appears that the .otf-table files are created by parsing the log files created during font creation. See scripts/build/mf-to-table.py So this means that your magic command would need to emit a keyword and a real value to the log file, and mf-to-table.py would need to be modified to read the keyword and the value and put it in the table file. Yes, and i'll also have to add a function to mf/feta-autometric.mf, similar to set_char_box. I'm finding the actual place in which the value is being output to logfile. But there's another question: currently all glyphs in feta-noteheadsFONTSIZE.log have the same amount of characteristics. Adding another values only to the flags, if at all possible, would perhaps make reading the logfiles more diffucult. Perhaps it would be good to move flags into a separate font file? (i.e. separate feta-noteheads into actual feta-noteheads and feta-flags) There is another rationale for doing this: i'm pretty sure that there's a limit of 256 glyphs per font. Until now there were only a handful of flags, but we're going to have many dozens of them; it's quite possible that either now or in the future we will reach the 256 glyph limit. What do you think? I remember that i tried doing this separation, but something didn't work. I hope i have that draft somewhere though. On 6/9/11 9:02 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Carl, you are great! After struggling with this shortened-flags issue for 5 months, i wouldn't have enough motivation to continue my work without your help! Right now I'm reading all the stuff that i did to remind myself where i am. As for now it looks that you are pointing me in the right direction! Glad to be of help! I really do like your work, and I want to see it implemented in LilyPond. I'm so happy to hear this! Sometimes i have the impression that noone really cares. And wait till i start another project! It's gonna be about ties ;) Maybe i'll finish it before Lily 3.0... cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/9/11 3:18 PM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: 2011/6/8-9 Carl Sorensen c_soren...@byu.edu: After looking more at this, it appears that the .otf-table files are created by parsing the log files created during font creation. See scripts/build/mf-to-table.py So this means that your magic command would need to emit a keyword and a real value to the log file, and mf-to-table.py would need to be modified to read the keyword and the value and put it in the table file. Yes, and i'll also have to add a function to mf/feta-autometric.mf, similar to set_char_box. I'm finding the actual place in which the value is being output to logfile. But there's another question: currently all glyphs in feta-noteheadsFONTSIZE.log have the same amount of characteristics. Adding another values only to the flags, if at all possible, would perhaps make reading the logfiles more diffucult. Perhaps it would be good to move flags into a separate font file? (i.e. separate feta-noteheads into actual feta-noteheads and feta-flags) That sounds to me like a reasonable approach. Rather than messing with feta-autometric, you can define your own feta-flag-autometric. There is another rationale for doing this: i'm pretty sure that there's a limit of 256 glyphs per font. Until now there were only a handful of flags, but we're going to have many dozens of them; it's quite possible that either now or in the future we will reach the 256 glyph limit. I think that's reasonable. feta-noteheads was already separated because of hitting the 256 glyph limit when we added shape noteheads in multiple styles. What do you think? I remember that i tried doing this separation, but something didn't work. I hope i have that draft somewhere though. I think that what causes problems is you lose the definition of black-notehead-width (which comes from feta-noteheads). On 6/9/11 9:02 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Carl, you are great! After struggling with this shortened-flags issue for 5 months, i wouldn't have enough motivation to continue my work without your help! Right now I'm reading all the stuff that i did to remind myself where i am. As for now it looks that you are pointing me in the right direction! Glad to be of help! I really do like your work, and I want to see it implemented in LilyPond. I'm so happy to hear this! Sometimes i have the impression that noone really cares. And wait till i start another project! It's gonna be about ties ;) Maybe i'll finish it before Lily 3.0... Great! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
Perhaps it would be good to move flags into a separate font file? (i.e. separate feta-noteheads into actual feta-noteheads and feta-flags) There is another rationale for doing this: i'm pretty sure that there's a limit of 256 glyphs per font. Until now there were only a handful of flags, but we're going to have many dozens of them; it's quite possible that either now or in the future we will reach the 256 glyph limit. LGTM. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/1/11 9:39 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Please help! I'm not ignoring you, but I have no idea on this! I'm sorry, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parameters in metafont files
On 6/1/11 9:39 AM, Janek Warchoł lemniskata.bernoull...@gmail.com wrote: Hi again :) Congrats on 0 criticals! I have a question about parameters in metafont files: i want to create something similar to mf/out/feta20.otf-table, but i don't understand how it's done (i tried to find bbox and attachment in mf files or scripts/build/gen-emmentaler-scripts.py, but there are no results). I also tried adding autometric_parameter (someBogusName, someValue); inside mf code, but there were no results. Here is roughly what i want to achieve: add a magical command to feta-flags.mf fet_beginchar (8th Flag (up), u3); [...] % flags.u3 definition magical_command (arbitraryRealValueChosenByMe); fet_endchar; fet_beginchar (16th Flag (up), u4); [...] % flags.u4 definition magical_command (anotherArbitraryRealValueChosenByMe); fet_endchar; [...] and have it output a flags.otf-table file looking like this (flags . (u . ((3 . (arbitraryRealValueChosenByMe)) (4 . (anotherArbitraryRealValueChosenByMe)) [...] )) . (d . [...] ))) Please help! After looking more at this, it appears that the .otf-table files are created by parsing the log files created during font creation. See scripts/build/mf-to-table.py So this means that your magic command would need to emit a keyword and a real value to the log file, and mf-to-table.py would need to be modified to read the keyword and the value and put it in the table file. HTH, Carl Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
