On Fri, Feb 17, 2012 at 6:00 AM, [email protected]
<[email protected]> 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 - [email protected] - http://www.xs4all.nl/~hanwen
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
