 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.06.2018 um 17:07 schrieb jr:
> hi,
>
> Le_Forgeron <jgr### [at] free fr> wrote:
>> You would like support of unicode 1D100...1D1FF like in freeserif
>
> I wrote a little test scene to see but cannot access that range.
>
> the docs (3.3.1.9.4 + 3.3.2.7.2) specify a 64K limit on the chr() function, as
> well as for the corresponding literal ("\uNNNN").
>
> how does one access font glyphs located after the limit?
At present you simply can't: POV-Ray's innards have never grown beyond
the old UCS-2 standard (yet); in other words, it only supports
characters from the Basic Multilingual Plane, period.
Here are the key components that have to be changed to get there:
(1a) The `\uNNNN` escape sequence has to be extended to allow for 6 hex
digits; in the current parser update, I'm implementing this as
`\Unnnnnn` (note the uppercase U); or
(1b) the `\uNNNN` escape sequence has to be re-defined to specify UTF-16
code units (rather than UCS-2 code points).
(2) The internal string representation in the parser has to be changed
from UCS-2 to /something/ else; I'm leaning towards UTF-32 encoded UCS-4
because it means keeping string length related stuff simple and
unambiguous. (This would also extend the numeric range of the `chr()`
and `asc()` functions.)
(3) The TrueType handling code needs to be extended to look for `cmap`
types 0/4 and 3/10 (currently: 0/3, 1/0, 3/0 and 3/1), and support
`cmap` format 12.0 (currently: 0, 4 and 6).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My goto resource for this sort of thing is LilyPond
(http://lilypond.org/), an open source music typesetting program.
From what I can see there's a "Feta" font included with it
(http://lilypond.org/doc/v2.19/Documentation/notation/the-emmentaler-font),
presumably in OpenType format, although maybe you could convert to TT
yourself. I also found links to these other music fonts, also not in TT
format as far as I know, but again maybe you can convert:
https://www.chiark.greenend.org.uk/~sgtatham/gonville/
http://www.smufl.org/fonts/
On 6/16/2018 4:42 AM, jr wrote:
> hi,
>
> I'm looking for a TT font that has all/many notes and other musical notation
> symbols. must be free to use, recommendations please. thanks.
>
>
> regards, jr.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/18/2018 12:38 PM, clipka wrote:
> Am 18.06.2018 um 17:07 schrieb jr:
>> hi,
>>
>> Le_Forgeron <jgr### [at] freefr> wrote:
>>> You would like support of unicode 1D100...1D1FF like in freeserif
>>
>> I wrote a little test scene to see but cannot access that range.
>>
>> the docs (3.3.1.9.4 + 3.3.2.7.2) specify a 64K limit on the chr() function, as
>> well as for the corresponding literal ("\uNNNN").
>>
>> how does one access font glyphs located after the limit?
>
> At present you simply can't: POV-Ray's innards have never grown beyond
> the old UCS-2 standard (yet); in other words, it only supports
> characters from the Basic Multilingual Plane, period.
>
> Here are the key components that have to be changed to get there:
>
> (1a) The `\uNNNN` escape sequence has to be extended to allow for 6 hex
> digits; in the current parser update, I'm implementing this as
> `\Unnnnnn` (note the uppercase U); or
>
> (1b) the `\uNNNN` escape sequence has to be re-defined to specify UTF-16
> code units (rather than UCS-2 code points).
>
> (2) The internal string representation in the parser has to be changed
> from UCS-2 to /something/ else; I'm leaning towards UTF-32 encoded UCS-4
> because it means keeping string length related stuff simple and
> unambiguous. (This would also extend the numeric range of the `chr()`
> and `asc()` functions.)
>
> (3) The TrueType handling code needs to be extended to look for `cmap`
> types 0/4 and 3/10 (currently: 0/3, 1/0, 3/0 and 3/1), and support
> `cmap` format 12.0 (currently: 0, 4 and 6).
>
Doesn't preclude the need for full plane 0+ support, but I'll mention a
few years ago I was playing in POV-Ray with Egyptian hieroglyphs in
particular - as well as a couple other plane 1 and plane 2 fonts.
Using the AegyptusSubset.ttf at:
https://mjn.host.cs.st-andrews.ac.uk/egyptian/fonts/newgardiner.html
I could render the 13044 human with club/staff character with:
#declare Text00 = text {
ttf "AegyptusSubset.ttf" "\uE044"
0.1, 0
pigment { color Color00 }
translate <0,0,-0.05>
no_shadow
}
In other words, while I never worked out how it works, once you find the
'wrapped' base hex value you can index from there so long as working
with an extracted font with just the plane 1 or 2 values. I was already
working with font subsets of plane 1 and 2 so unsure how to extract just
plane 1 or plane 2 from a font with plane 0 too. A potential hack to get
at planes 1 and 2 today - for what it's worth I guess.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.06.2018 um 02:39 schrieb William F Pokorny:
> Doesn't preclude the need for full plane 0+ support, but I'll mention a
> few years ago I was playing in POV-Ray with Egyptian hieroglyphs in
> particular - as well as a couple other plane 1 and plane 2 fonts.
>
> Using the AegyptusSubset.ttf at:
>
> https://mjn.host.cs.st-andrews.ac.uk/egyptian/fonts/newgardiner.html
>
> I could render the 13044 human with club/staff character with:
>
> #declare Text00 = text {
> }
>
> In other words, while I never worked out how it works, once you find the
> 'wrapped' base hex value you can index from there so long as working
> with an extracted font with just the plane 1 or 2 values. I was already
> working with font subsets of plane 1 and 2 so unsure how to extract just
> plane 1 or plane 2 from a font with plane 0 too. A potential hack to get
> at planes 1 and 2 today - for what it's worth I guess.
Actually that's still accessing the BMP, and it's not a hack but a
feature of that particular font: Since it only deals in hieroglyphs, it
can provide a mapping of all its glyphs into the Private Use Area of the
BMP (U+E000 to U+F8FF).
"Complete" fonts do not have this luxury, as the currently assigned code
points outside the BMP far exceed the 6400 code points of the BMP
Private Use Area.
Also, even specialized fonts are not required to provide such a Private
Use Area mapping.
Even if a font provides a PUA mapping, the mapping may be systematically
different from the officially assigned mapping outside the BMP. For
example, the PUA mapping might reflect an experimental mapping predating
official inclusion into the Unicode standard.
And last not least, applications dealing with UCS characters are free to
use Private Use Area code points for special purposes, so there's no
guarantee that future versions of POV-Ray will continue to provide full
support for this mechanism; for instance, in overhauling the parser I
was (and still am) toying with the idea of setting aside 128 of those
code points to internally represent non-ASCII octets from source files
for which the character encoding is not (yet) known; such code points
would be translated "back" by a later stage of the parser, even if they
happen to have been entered via "\uNNNN".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kevin Wampler <nob### [at] nowherenet> top posted:
> My goto resource for this sort of thing is LilyPond
> (http://lilypond.org/), an open source music typesetting program.
>
> From what I can see there's a "Feta" font included with it
> (http://lilypond.org/doc/v2.19/Documentation/notation/the-emmentaler-font),
> presumably in OpenType format, although maybe you could convert to TT
> yourself. I also found links to these other music fonts, also not in TT
> format as far as I know, but again maybe you can convert:
>
> https://www.chiark.greenend.org.uk/~sgtatham/gonville/
> http://www.smufl.org/fonts/
I've no s/ware to convert to TTF, but thank you.
jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/19/2018 02:57 AM, clipka wrote:
> Am 19.06.2018 um 02:39 schrieb William F Pokorny:
>
>> Doesn't preclude the need for full plane 0+ support, but I'll mention a
>> few years ago I was playing in POV-Ray with Egyptian hieroglyphs in
>> particular - as well as a couple other plane 1 and plane 2 fonts.
>>
>> Using the AegyptusSubset.ttf at:
>>
>> https://mjn.host.cs.st-andrews.ac.uk/egyptian/fonts/newgardiner.html
>>
>> I could render the 13044 human with club/staff character with:
>>
>> #declare Text00 = text {
>> }
>>
>> In other words, while I never worked out how it works, once you find the
>> 'wrapped' base hex value you can index from there so long as working
>> with an extracted font with just the plane 1 or 2 values. I was already
>> working with font subsets of plane 1 and 2 so unsure how to extract just
>> plane 1 or plane 2 from a font with plane 0 too. A potential hack to get
>> at planes 1 and 2 today - for what it's worth I guess.
>
> Actually that's still accessing the BMP, and it's not a hack but a
> feature of that particular font: Since it only deals in hieroglyphs, it
> can provide a mapping of all its glyphs into the Private Use Area of the
> BMP (U+E000 to U+F8FF).
>
> "Complete" fonts do not have this luxury, as the currently assigned code
> points outside the BMP far exceed the 6400 code points of the BMP
> Private Use Area.
>
> Also, even specialized fonts are not required to provide such a Private
> Use Area mapping.
>
> Even if a font provides a PUA mapping, the mapping may be systematically
> different from the officially assigned mapping outside the BMP. For
> example, the PUA mapping might reflect an experimental mapping predating
> official inclusion into the Unicode standard.
>
> And last not least, applications dealing with UCS characters are free to
> use Private Use Area code points for special purposes, so there's no
> guarantee that future versions of POV-Ray will continue to provide full
> support for this mechanism; for instance, in overhauling the parser I
> was (and still am) toying with the idea of setting aside 128 of those
> code points to internally represent non-ASCII octets from source files
> for which the character encoding is not (yet) known; such code points
> would be translated "back" by a later stage of the parser, even if they
> happen to have been entered via "\uNNNN".
>
Thanks much for the explanation. It means too I was likely working with
extracted font bits mapped differently. The other extracted fonts at the
time didn't have the offset to U+E000, but rather acted like plane 0
fonts in total though they came from planes 1 and 2.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> (2) The internal string representation in the parser has to be changed
> from UCS-2 to /something/ else; I'm leaning towards UTF-32 encoded UCS-4
> because it means keeping string length related stuff simple and
> unambiguous. (This would also extend the numeric range of the `chr()`
> and `asc()` functions.)
there is a current thread on comp.lang.c which discusses this issue, subject
"fixed width unicode subsets".
regards ,jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.06.2018 um 15:12 schrieb jr:
> hi,
>
> clipka <ano### [at] anonymousorg> wrote:
>> (2) The internal string representation in the parser has to be changed
>> from UCS-2 to /something/ else; I'm leaning towards UTF-32 encoded UCS-4
>> because it means keeping string length related stuff simple and
>> unambiguous. (This would also extend the numeric range of the `chr()`
>> and `asc()` functions.)
>
> there is a current thread on comp.lang.c which discusses this issue, subject
> "fixed width unicode subsets".
Related, but (judging from a semi-cursory glance) nothing new to me in
there.
I know the how-to. What I need is a couple of round tuits.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just serendipitously found this:
https://web.archive.org/web/20080514063612/http://home.pacbell.net/tylereng/musical.zip
as part of:
https://web.archive.org/web/20080514063612/http://home.pacbell.net/tylereng/index.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wow, that is impressive!
On 6/18/2018 7:20 PM, Kevin Wampler wrote:
> My goto resource for this sort of thing is LilyPond
> (http://lilypond.org/), an open source music typesetting program.
>
> From what I can see there's a "Feta" font included with it
> (http://lilypond.org/doc/v2.19/Documentation/notation/the-emmentaler-font),
> presumably in OpenType format, although maybe you could convert to TT
> format as far as I know, but again maybe you can convert:
>
> https://www.chiark.greenend.org.uk/~sgtatham/gonville/
> http://www.smufl.org/fonts/
>
>
> On 6/16/2018 4:42 AM, jr wrote:
>> hi,
>>
>> I'm looking for a TT font that has all/many notes and other musical
>> notation
>>
>>
>> regards, jr.
>>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
