ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <j.hagen@xs4all.nl>
To: news3@nililand.de, mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: accessing glyphs in the private area
Date: Tue, 2 Oct 2018 11:29:46 +0200	[thread overview]
Message-ID: <c91b7ed4-2ab2-a5ba-1481-9cfcc7c47cc8@xs4all.nl> (raw)
In-Reply-To: <1tv75weq27x7z.dlg@nililand.de>

On 10/2/2018 9:29 AM, Ulrike Fischer wrote:
> Am Tue, 2 Oct 2018 06:55:02 +0200 schrieb luigi scarso:
> 
>>> For what do you reserve the space in the PUA?
> 
>>   http://www.pragma-ade.nl/general/manuals/fonts-mkiv.pdf
>> page 32 of the document :
>   
>> As we already mentioned in a previous chapter, in ConTeXt we use
>> Unicode internally. This also means that fonts are organized this
>> way. By default the glyph representation of a Unicode character
>> sits in the same slot in the glyph table. All additional glyphs,
>> like ligatures or alternates are pushed in the private unicode
>> space. This is why in the lists shown in the figures the
>> ligatures have a private Unicode number.
> 
> Hm. To clarify. In xetex there is clear distinction between the slot
> and unicode. \XeTeXglyph (slot) and \char (unicode) give different
> output and \char actively uses the tounicode mapping of the font.
> 
> \font\test="[lmroman10-regular.otf]"
> \test
> \XeTeXglyph"7A
> \char"7A
> \bye
>  
> In luatex \char and \Uchar don't really care about unicode, even if
> the font has tounicode=1 and tounicode entries, they access the char
> by the hashed integer number.

they access the char in the characters table (where each character has 
an index field so one can write a simple function that accesses it by 
index; also, i assume that in xetex \char gives the character as known 
to tex so if one input non-unicode one gets that)

> So to get "unicode" the font loader has to sort the glyphs, index
> unicode glyphs by their unicode code point, and assign "non-unicode"
> glyphs numbers that don't interfere.
> 
> Did I got right?

indeed, and we use the private space for those with no unicode (which 
can be a lot, also think for instance of the snippets that make up math 
extensibles)

> Then I do understand that you need some free numbers to push
> glyphes. But I do not understand why to achieve this you remove
> glyphs from their unicode points. The PUA is not some non-unicode
> wilderness. The code points there are as valid as in the other code
> blocks. You wouldn't move away the greek block to get the place, so
> why do you think it is okay to throw out of the PUA block what SIL
> and other font designers encoded there?  Can't you check for a free
> range instead?

sure, but then i also loose some functionality in context (unless i gho 
for ugly solutions) ... as all glyphs are supposed to have a name access 
by name is a pretty good alternative

the main issue is that there are fonts that use private > 0xFFFF space 
which then would mean a lot of extra mem for names ... so the question 
is are there fonts that use that range

Hans


-- 

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

  reply	other threads:[~2018-10-02  9:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-30 20:08 Ulrike Fischer
2018-10-01  8:20 ` Hans Hagen
2018-10-01  9:42   ` Ulrike Fischer
2018-10-01  9:53     ` luigi scarso
2018-10-01 17:29     ` Hans Hagen
2018-10-01 17:55       ` Ulrike Fischer
2018-10-01 20:42         ` Hans Hagen
2018-10-02  4:55         ` luigi scarso
2018-10-02  7:29           ` Ulrike Fischer
2018-10-02  9:29             ` Hans Hagen [this message]
2018-10-02 11:39               ` Ulrike Fischer
2018-10-02 12:42                 ` Hans Hagen
2018-10-01 21:11 David Carlisle
2018-10-02  9:13 ` Hans Hagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c91b7ed4-2ab2-a5ba-1481-9cfcc7c47cc8@xs4all.nl \
    --to=j.hagen@xs4all.nl \
    --cc=news3@nililand.de \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).