Character mappings in Pillow

[ThingamabobsCoding]

Hey there, as far as I understand pillow uses freetype.

There is a utility called character mapping. It can be handy to handle errors or for GUI applications to map the chars.

I don't see a hint that this is somewhat obtainable in documentation of pillow. Nor does font.font.glyphs returns something like that, I just know how many characters are available.
Is there any chance this will be implemented or already a hacky way to achieve this?

Consider something like this: https://www.1001fonts.com/hazard-signs-font.html
If you click on characters you can see how it is mapped.

[radarhere]

From my understanding, you would like to be able to map FreeType glyph indices to characters.

Considering that a proposed feature to check if a character is present at all in a font is stalled over debate about whether it is within our focus, no, I don't think that retrieving the underlying glyph index is in Pillow's scope.

I expect that freetype-py would offer you a solution instead.

[ThingamabobsCoding]

@radarhere I understand that in context of a image-lib there is only rudimentary support for text and fonts.
But I think symbols play a role in image-text and I believe having a character map is missing for it.

From my perspective checking if greek glyphs are in the font isn't in the scope but mapping symbols to the typed character is.

Thank you for your suggestion about freetype-py, but I rather don't have an extra dependency.
For my case it will be enough to refer to the documentation of the font and map them myself with a dictionary.
But I think it would be a cool feature to pillow in the future, since it is more or less already there and just not exported.

EDIT:
To make a clearer case pro implementation.
Working with pillow means working with images, just like Flyer, Handouts, Business Cards or Logos.
And for all examples there is often text needed, that's why imho pillow supports text in the first place.
In all the examples you almost always see symbols be used, such as phone, location, mail and so on.
So I would understand if you would reject an enhancement for Leading/Tracking/Kerning , but rejecting support for symbols is a little bit like rejecting punctuation or unicode, which is already supported by pillow.

So I think it's a complementary feature and not a new branch.

[radarhere]

rejecting support for symbols is a little bit like rejecting punctuation or unicode, which is already supported by pillow.

My understanding so far has been that you are asking for additional information about font characters.

When you say 'support for symbols' though, that sounds like you think that you're unable to draw a particular character in a font with Pillow. If that is the case, please provide an example.

[ThingamabobsCoding]

After thinking my argument above through again, I didn't made a good job with it.

I wanted to point out that you can use '.' and it will show '.' or I could use u"\u250c" and it shows '┌' which are all non-characters and that's why symbols should be accessible as well.
However the important distinction is that a font with symbols, does not necessarily come with a documentation (especially free ones) and therefore it would be appropriated to know which keys correspond with symbols.

Consider this: https://www.1001fonts.com/symbolix-font.html
It would take forever finding the right mapping without a programmatic inspection of the font or a documentation.
So again, it's just about image-font usage and not about font-magic/development.

Consider this font: https://www.1001fonts.com/waveform-font.html
I guess one could do cool stuff with a mask and this font, but without knowing what characters are mapped it's a pain.

[radarhere]

I wanted to point out that you can use '.' and it will show '.' or I could use u"\u250c" and it shows '┌' which are all non-characters and that's why symbols should be accessible as well.

If you want to write u"\u250c" and see '┌', you can. On my machine

from PIL import Image, ImageDraw, ImageFont, ImageText

font = ImageFont.truetype("/System/Library/Fonts/Supplemental/Times New Roman.ttf", 72)
text = ImageText.Text(u"\u250c", font)

im = Image.new("RGB", text.get_bbox()[2:])
d = ImageDraw.Draw(im)
d.text((0, 0), text)
im.save("out.png")

gives

However the important distinction is that a font with symbols, does not necessarily come with a documentation (especially free ones) and therefore it would be appropriated to know which keys correspond with symbols.

I'm not sure anymore if you're actually interested in character mapping and glyph indices.

It now sounds like you just want to be able to draw all characters possible from a font at once. I don't think that resembles any of the other APIs that Pillow offers - it sounds like code that an end user such as yourself would write. Couldn't you just iterate through possible font characters, and show the visual output?

[ThingamabobsCoding]

@radarhere I ended up following your advice and got to use freetype-py. The rationale behind this issue was primary about so called dingbat fonts. A font that contains mainly symbols and not character. It is true that one is able to write the unicode representation in python and end up with text.

So the case-rendering is:
I have dingbat-font and want to draw the content. -> A valid request of a pillow-user(?).
The dingbat-font may or may not have a unicode charmap. -> Charmaps other than unicode currently supported ?
In the charmap a arbitrary number of glyphs is available. -> This number is already available
But I don't know what index/unicode-representation is used by the font-developer. -> That's the issue.

I will approach this need for my personal use-case with freetype-py and implement it like Microsoft word has with a interactive charmap.
However, for a PIL user that is not necessarily an available option. So you guys can dismiss this as "We don't support dingbat", which I would find unreasonable, but understandable. Or you guys say we want to support dingbat fonts for making cool effects and other interesting image-text stuff possible but then have to make the charmaps somewhere programmatically available/inspectable.

The code below isn't tested yet and you need to be caution about it. However, the first attempt to solve my personal issue will be the following function, where self.FT = freetype.FT_Face(...:

    def chars(self):
        '''
        This generator function is used to return all unicode character
        codes in the current charmap of a given face. For each character it
        also returns the corresponding glyph index.

        **Note**
            Character codes can have values up to 0xFFFFFFFF (4_294_967_295).
            Unicode cmaps provide normally to 0x1FFFFF (2_097_151) character.
        '''
        idx     = ft.FT_UInt()
        char    = ft.FT_Get_First_Char(self.FT, ft.byref(idx))
        value   = idx.value
        yield char, val
        all_    = self.numglyphs
        while value != all_:
            char    = ft.FT_Get_Next_Char(self.FT, char, ft.byref(idx))
            value   = idx.value
            yield char, value

[radarhere]

If you have text, and you want to render it using a font, that should work, provided the font supports the text that you're requesting.

But I don't know what index/unicode-representation is used by the font-developer. -> That's the issue.

Here's the part that confuses me.
If you know what font character you want before you use Pillow code, then it's because you looked at the font in another tool, and that other tool could potentially be one that tells you unicode values.
If you don't know what font character you want, then... you want to draw... I don't know what the question would be. Except for this specific scenario where you want to draw all characters in a font.

I also don't know what you would do with the glyph index that your code returns. I don't see anywhere in Pillow that accepts them.

Perhaps the distinction is that I'm thinking of a font as a way to render text, and you're thinking of a font as an icon library. Pillow supports drawing text using a font. It doesn't support drawing characters from a font irrespective of text. If many more users request this, it can of course be reconsidered.

Here's my attempt at iterating through font characters with Pillow

from PIL import Image, ImageDraw, ImageFont, ImageText

font = ImageFont.truetype("/System/Library/Fonts/Supplemental/Times New Roman.ttf", 72)

missing_text = u"\ufffd"
missing_size = font.getbbox(missing_text)[2:]
im = Image.new("L", missing_size)
draw = ImageDraw.Draw(im)
draw.text((0, 0), u"\ufffd", font=font)
missing_bytes = im.tobytes()

for i in range(65536):
    text = chr(i)
    if text != missing_text:
        size = font.getbbox(text)[2:]
        if size == missing_size:
            im = Image.new("L", size)
            d = ImageDraw.Draw(im)
        
            t = ImageText.Text(text, font)
            d.text((0, 0), t)
            
            if im.tobytes() == missing_bytes:
                continue
    print(i)

[ThingamabobsCoding]

If you know what font character you want before you use Pillow code, then it's because you looked at the font in another tool, and that other tool could potentially be one that tells you unicode values. If you don't know what font character you want, then... you want to draw... I don't know what the question would be. Except for this specific scenario where you want to draw all characters in a font.

I would argue that is dependent on how the font was distributed and or if it came with a documentation. That's why I referenced this font in my comment here

Perhaps the distinction is that I'm thinking of a font as a way to render text, and you're thinking of a font as an icon library.

Well if you look at your keyboard that most likely has the ASCII symbols on it, that argument that you make seems vague to me. Semantically an icon is just another symbol with another meaning. That's what I meant with PIL already supports unicode and more than just characters and like the "telephone icon" / a CJK character "㑟 (13407) " / or greek "𝞏 (120719)" - a user may want to include, there is also the user that want's to use font symbols as mask for other fancy things. Since there are more than 4 billion possible places, it would take for ever to iterate over them all. That's why I thought suggesting this here might makes sense.

I don't try to convince you if you simply don't like the idea. But there seems to be a legitimate use-case that can be served with little effort and doesn't add much complexity to the lib or would stretch the scope of this lib, it's just an additional utility.

[radarhere]

@hugovk did you want to weigh in on this?

[aclark4life]

Any relation to these historical commits ?

./src/_imagingft.c: * 2003-09-27 fl  Added charmap encoding support
./src/_imagingft.c:        error = FT_Select_Charmap(self->face, encoding_tag);
./src/PIL/ImageFont.py:# 2003-09-27 fl   added support for truetype charmap encodings

It looks like something that if @ThingamabobsCoding sent a PR and the PR was easy to review and we didn't have any good reason not to implement then we'd merge. Are we (Pillow team) going to do this? I'm not convinced of that yet based on the target audience being small and the effort to implement presumably not as small.

[ThingamabobsCoding]

@aclark4life I'm unaware how pillow implements freetype, e.g making their own binaries, but I don't think the effort is substantially. I believe pillow.ImageFont().font looks like it is the FT_Face and all you have to do is to look at this https://github.com/rougier/freetype-py/blob/master/freetype/__init__.py#L1382

[hugovk]

@hugovk did you want to weigh in on this?

1. You don't want the dedicated freetype-py as an extra dependency
2. In your case, it's enough to have a mapping, so you don't actually need this feature in freetype-py or in Pillow
3. It would just be a cool feature in Pillow

So this is a theoretical feature request, with no concrete need, and it's (likely?) already available in a dedicated package.

I don't think we need to add this.

[ThingamabobsCoding]

I really don't want to start all over again. I think this can be closed as not interested.