On Fri, Feb 17, 2012 at 6:00 AM, m...@apollinemike.com <m...@apollinemike.com> wrote: >> This sounds wrong. Where does this data come from ultimately? >> > > The svg files. I read them into lilypond and generate this informatin.
You mean the SVG fonts? The SVG files are generated by FF in the same step as the OTF files. I suspect that whatever you need is easier to generate in FF directly. You could ask around on the fontforge mailing list. >> Without knowing more, I suspect this data should be computed at font >> generation time, and it should be embedded in the OTF file. > > It is created at font generation time (git grep font-cache.scm in > mf/GNUmakefile) but it is not part of the otf-table. which branch has the latest version of this? > As I said, I'd like to do this, but I'm not comfortable enough with build to > know how its done. Where and when are these files generated? Are they > generated by metafont or python or look at scripts/build/mf-to-table.py Then there is scripts/build/gen-emmentaler-scripts.py which generates a FontForge script file (.pe since it used to be called PfaEdit) in mf/out/emmentaler-XX.pe. The calls look like this, LoadTableFromFile("LILC", "feta11.otf-table"); > This doesn't seem impossible, but I'd want to make sure it's the right way to >go. The advantage of font-cache.scm is that it defines box-hash in LilyPond >at runtime, and as hash-table-lookups are in constant time, this is lightning >fast compared to an alist, which is in linear time. I'd store a separate hashtable of codepoint => list of boxes directly in the OpenTypeFont struct. > A separate issue should be opened in the tracker to use hash-tables instead > of alists for otf tables. but it is using hashtables; check out Open_type_font::Open_type_font (FT_Face face) the alist are converted to hash tables. >I'm trying to think of this project in separable, manageable chunks. I'd like >the first chunk to be the pushing of the skyline code you see on Rietveld so >that there is a direct effect straightaway in scores & so that we can get user >feedback before we make infrastructural changes (which may depend on what >people wind up asking for after the change). I'd rather not introduce more fragility (cf the generated .scm files) into the build process which is complicated enough as it is. I think users can wait for another week if need be. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel