lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Metafont optional parameters


From: Carl Sorensen
Subject: Re: Metafont optional parameters
Date: Mon, 1 Jun 2020 18:48:34 +0000
User-agent: Microsoft-MacOutlook/10.10.16.200509

You’re correct, of course.

Encodingdefs.ps assigns ps glyph ids, not Unicode encoding.

It’s been long enough since I worked on this that I’m apparently fuzzy.

Sorry for the noise.

Carl





From: Owen Lamb <owendlamb@gmail.com>
Date: Monday, June 1, 2020 at 12:17 PM
To: Carl Sorensen <carl.d.sorensen@gmail.com>
Cc: Werner LEMBERG <wl@gnu.org>, "lilypond-devel@gnu.org" 
<lilypond-devel@gnu.org>
Subject: Re: Metafont optional parameters

Hi Carl,

Thanks for bringing this file to my attention. It seems to me, however, that 
the Unicode encoding is defined in 
gen-emmentaler.fontforge.py<http://gen-emmentaler.fontforge.py>, at lines 58 
through 61, with a simple iterator starting at 0xE000. (This is what I'm 
planning to replace with manually defined SMuFL codepoints, taken from the .mf 
files.)

AFAICT, encodingdefs.ps<http://encodingdefs.ps> doesn't seem to have a bearing 
on the final Unicode encoding. The first glyph mentioned in 
encodingdefs.ps<http://encodingdefs.ps> ("noteheads.d0doFunk"), there given the 
value 0x01 in the LilyNoteHeadEncoding list, has a value of 0xE0F5 in the 
generated emmentaler fonts, and is nowhere near being the lowest-value notehead 
character in the PUA. Perhaps encodingdefs.ps<http://encodingdefs.ps> deals 
with a different, font-specific, category-dependent character map, while the 
python script defines the Unicode encoding?

Thanks,
Owen

On Sat, May 30, 2020 at 7:07 PM Carl Sorensen 
<carl.d.sorensen@gmail.com<mailto:carl.d.sorensen@gmail.com>> wrote:
On Sat, May 30, 2020 at 4:41 PM Owen Lamb 
<owendlamb@gmail.com<mailto:owendlamb@gmail.com>> wrote:
>
> Hi all,
>
> I'd like to add an optional parameter for smuflcode to fet_beginchar, so
> that I don't have to take two lines redeclaring the variable in every
> glyph. Ideally, it won't have to be optional once every character has it,
> but in the meantime, it would help with testing individual characters' new
> encodings.

I thought that the font encodings were created in the process of
converting to Type 1 fonts by postscript using the information in
ps/encodingdefs.ps<http://encodingdefs.ps>

Is that the case?

Carl

reply via email to

[Prev in Thread] Current Thread [Next in Thread]