Font: reorganize Special Characters menu with submenus #106240

Closed
Damien Picard wants to merge 2 commits from pioverfour:dp_font_special_characters into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

Many new characters are introduced, split into 10 submenus: Math,
Fraction, Subscript, Superscript, Quotation Mark, Dash, Punctuation,
Currency, Intellectual Property.

The choice of characters included is of course arbitrary, but not any
more than before. It is based on what I believe may be most commonly
useful for users, or at least users using Western Scripts.

They are all characters which are hard to input with an ordinary
keyboard layout (QWERTY, AZERTY, QWERTZ, etc.) as opposed to
nerd-friendly, Dvorak-type layouts.

Since this is not so common an operation, I believe it warrants adding
a new level of menus so as not to have dozens of characters in one
menu.

  • Many common math symbols were added, as well as common fractions.
  • Superscript 1, 2, 3 were extended to 0, and completed by subscripts.
  • Copyright and Registered Trademark were completed by TM and Sound
    Recording Copyright.
  • "Double <<" and "Double >>" were moved to a "Quotation" menu and
    renamed to Left and Right Guillemet, respectively, as they are
    unrelated to the less than and greater than signs. These were
    completed by other characters useful for quoting in various languages.
  • The Promillage was moved to Math symbols and renamed "Per Mille" as
    it seems to actually be Dutch (?).
  • Circle was removed, as the character was invalid and had apparently
    been for many years. It is not obvious what circle character it was
    intended to add, and this is not such a common sign anyway.
  • The Dutch Florin, British Pound and Japanese Yen were stripped of
    their countries, because the symbols may be used for other
    currencies. In fact the Florin was renamed to "Currency Sign" as
    that is what it is. They were moved to their own menu, along with
    new characters Cent, Euro, and Dollar--although this last one is easy to
    input with any ordinary keyboard.
  • Eszett ("German S") was removed, based on the assumption that people
    most likely to use it are German speakers and probably use or can
    switch to a layout enabling them to input it.
  • "Spanish question mark" and "Spanish exclamation mark" were moved to
    a "Punctuation" menu, along with many new characters.
  • A new Dash menu was added.

Each menu entry now shows the name of the character, followed by the
char itself, to make it easier to choose visually.

In addition, add a shortcut to the default keymap to input special characters

Adding special characters is not a very common operation, but it may
be useful for certain workflows to be able to do it using a shortcut.

The new shortcut is Ctrl + Shift + A in font edit mode: kind of like
Shift + A for Add, but that is of course already taken by "Insert A".


One issue with this patch is that the default font, BlenFont, does not contain all the glyphs. The primes, fractions, sub- and superscripts, as well as some punctuation are missing from it. DejaVu Sans Book does though, and it may eventually replace bfont as the default font for text objects.
In any case the current state of this menu is not fully functional either, so it is still worth it.

Before After
Main menu image image
Submenus image
Result image image
Many new characters are introduced, split into 10 submenus: Math, Fraction, Subscript, Superscript, Quotation Mark, Dash, Punctuation, Currency, Intellectual Property. The choice of characters included is of course arbitrary, but not any more than before. It is based on what I believe may be most commonly useful for users, or at least users using Western Scripts. They are all characters which are hard to input with an ordinary keyboard layout (QWERTY, AZERTY, QWERTZ, etc.) as opposed to nerd-friendly, Dvorak-type layouts. Since this is not so common an operation, I believe it warrants adding a new level of menus so as not to have dozens of characters in one menu. - Many common math symbols were added, as well as common fractions. - Superscript 1, 2, 3 were extended to 0, and completed by subscripts. - Copyright and Registered Trademark were completed by TM and Sound Recording Copyright. - "Double <<" and "Double >>" were moved to a "Quotation" menu and renamed to Left and Right Guillemet, respectively, as they are unrelated to the less than and greater than signs. These were completed by other characters useful for quoting in various languages. - The Promillage was moved to Math symbols and renamed "Per Mille" as it seems to actually be Dutch (?). - Circle was removed, as the character was invalid and had apparently been for many years. It is not obvious what circle character it was intended to add, and this is not such a common sign anyway. - The Dutch Florin, British Pound and Japanese Yen were stripped of their countries, because the symbols may be used for other currencies. In fact the Florin was renamed to "Currency Sign" as that is what it is. They were moved to their own menu, along with new characters Cent, Euro, and Dollar--although this last one is easy to input with any ordinary keyboard. - Eszett ("German S") was removed, based on the assumption that people most likely to use it are German speakers and probably use or can switch to a layout enabling them to input it. - "Spanish question mark" and "Spanish exclamation mark" were moved to a "Punctuation" menu, along with many new characters. - A new Dash menu was added. Each menu entry now shows the name of the character, followed by the char itself, to make it easier to choose visually. In addition, add a shortcut to the default keymap to input special characters Adding special characters is not a very common operation, but it may be useful for certain workflows to be able to do it using a shortcut. The new shortcut is Ctrl + Shift + A in font edit mode: kind of like Shift + A for Add, but that is of course already taken by "Insert A". ----- One issue with this patch is that the default font, BlenFont, does not contain all the glyphs. The primes, fractions, sub- and superscripts, as well as some punctuation are missing from it. DejaVu Sans Book does though, and it may eventually replace bfont as the default font for text objects. In any case the current state of this menu is not fully functional either, so it is still worth it. | | Before | After | |-----------|-------------------------------------------------------------|-------------------------------------------------------------| | Main menu | ![image](/attachments/7c122de7-3453-42a3-b8bd-2de6b4f97190) | ![image](/attachments/e2f9cdca-232d-4619-a215-f43ad088f299) | | Submenus | | ![image](/attachments/27b799d2-cfd8-4621-b5b5-e39165988a45) | | Result | ![image](/attachments/b172b318-0baf-41e0-8a38-f2ee4c962dc4) | ![image](/attachments/963a5f46-9259-4df1-b9bd-6c7165a20a3c) |
Damien Picard added the
Module
User Interface
label 2023-03-28 20:07:41 +02:00
Damien Picard added this to the User Interface project 2023-03-28 20:10:26 +02:00
Damien Picard force-pushed dp_font_special_characters from 41c142b824 to 742bba4647 2023-03-30 09:12:14 +02:00 Compare

Personally I'd instead remove this menu. This feels like a feature that no longer exists in many applications because either an operating system tool or a web search can be used instead, and a menu like this can not hope to be anywhere near complete.

Personally I'd instead remove this menu. This feels like a feature that no longer exists in many applications because either an operating system tool or a web search can be used instead, and a menu like this can not hope to be anywhere near complete.

Maybe @Harley has an opinion on this.

Maybe @Harley has an opinion on this.
Member

I do have opinions and will probably write an essay here. LOL

One issue with this patch is that the default font, BlenFont, does not contain all the glyphs

We could expose BLF_has_glyph in the python API so you could disable the items that aren't in the current font.

My main "issue" with this isn't really about your patch, but more about what this is all for generally. Is it really about finding a specific character or is it about exploring what is in the current font?

With the UI it is different and simpler. We make almost all the characters available using the fallback stack. You want some weird character? You will get one. So the problem there is just in knowing which Unicode codepoint out of the hundreds of thousands that you want.

But with Text Objects the user is almost always using a very specific font. So if they need a particular character it can only be from that same font. So here the problem is more about finding what is in this one font.

So I can see some benefit in a larger solution, like a popup designed to explore just the characters in the current font. A dropdown list of the different Unicode blocks found in that font followed by the characters in that block. So if the font contains anything in U+20A0-U+20C0 the list includes "Currency Symbols" and then shows only glyphs in that range found in the font.

I can see some benefit in allow direct entry of Unicode characters, like I demonstrated here: https://developer.blender.org/D13447

I can also see some benefit in supporting platform-specific extended text entry. As in Windows Alt codes and similar found on Macs. Alt+13 for ♪ for example on Windows. Option+3 for £ on Mac.

But otherwise I agree with Brecht. The existing menu has always seemed a bit half-baked, but extending it will make it worse in some ways. I can easily imagine bug reports about how they selected "Asterism" and got nothing. In fact they tried almost all the menu items and nothing came out. We ask what font they were using, they tell us some custom "Jetsons" font and we have to explain yet again about how fonts work.

We don't really have this problem if we rely on users to copy and paste characters from elsewhere, use OS-supplied tools to explore fonts, select characters, etc.

Maybe we can add some better entry types like mentioned above AND remove the menu for version 4.0? Might seem like an okay trade.

I do have opinions and will probably write an essay here. LOL > One issue with this patch is that the default font, BlenFont, does not contain all the glyphs We *could* expose BLF_has_glyph in the python API so you could disable the items that aren't in the current font. My main "issue" with this isn't really about your patch, but more about what this is all for generally. Is it really about finding a specific character or is it about exploring what is in the current font? With the UI it is different and simpler. We make almost all the characters available using the fallback stack. You want some weird character? You will get one. So the problem there is just in knowing which Unicode codepoint out of the hundreds of thousands that you want. But with Text Objects the user is almost always using a *very specific font*. So if they need a particular character it can only be from that **same font**. So here the problem is more about finding what is in this one font. So I can see some benefit in a larger solution, like a popup designed to explore just the characters in the current font. A dropdown list of the different [Unicode blocks](https://en.wikipedia.org/wiki/Unicode_block) found in that font followed by the characters in that block. So if the font contains anything in U+20A0-U+20C0 the list includes "Currency Symbols" and then shows only glyphs in that range found in the font. I can see *some* benefit in allow direct entry of Unicode characters, like I demonstrated here: https://developer.blender.org/D13447 I can also see *some* benefit in supporting platform-specific extended text entry. As in Windows Alt codes and similar found on Macs. Alt+13 for ♪ for example on Windows. Option+3 for £ on Mac. But otherwise I agree with Brecht. The existing menu has always seemed a bit half-baked, but extending it will make it worse in some ways. I can easily imagine bug reports about how they selected "Asterism" and got nothing. In fact they tried almost all the menu items and nothing came out. We ask what font they were using, they tell us some custom "Jetsons" font and we have to explain yet again about how fonts work. We don't really have this problem if we rely on users to copy and paste characters from elsewhere, use OS-supplied tools to explore fonts, select characters, etc. Maybe we can add some better entry types like mentioned above AND remove the menu for version 4.0? Might seem like an okay trade.
Author
Member

I actually agree with you both. “The existing menu has always seemed a bit half-baked” sums up my opinion pretty well!

My reasoning for submitting this PR was like: “Wait, where do these weird translations come from? Oh, interesting menu! Oh, interesting… This doesn’t work very well, I’m sure few people know this even exists. Well, since it’s there, might as well make something I’d at least have some use for once in a while”.

But yeah, removing the menu for 4.0 sounds good—or even before then. I’m not even sure a selector popup for the current font would be worth spending time designing, as other solutions exist at the OS-level.

Proper Unicode entry would be very cool though!

I actually agree with you both. “The existing menu has always seemed a bit half-baked” sums up my opinion pretty well! My reasoning for submitting this PR was like: “Wait, where do these weird translations come from? Oh, interesting menu! Oh, *interesting*… This doesn’t work very well, I’m sure few people know this even exists. Well, since it’s there, might as well make something I’d at least have some use for once in a while”. But yeah, removing the menu for 4.0 sounds good—or even before then. I’m not even sure a selector popup for the current font would be worth spending time designing, as other solutions exist at the OS-level. Proper Unicode entry would be very cool though!
Member

Proper Unicode entry would be very cool though!

I haven't been able to convince anyone else of that yet, but I might dust off that patch and see how it could work with text objects. The idea is you could hold down ALT key (or Option on Mac), type a Unicode codepoint value (in regular Hex format), then release ALT and get that character. So hold down Alt, then enter "21e7", release it and get a ⇧

One thing I noticed today when looking at this is that we don't return a "not.def" (tofu) character when a glyph is not found in the current font for Text Objects. We just swallow it and return nothing, at least when copying and pasting. Showing tofu 𲎠 or replacement character � or maybe a character from our last resort font might help explain better what is going on.

> Proper Unicode entry would be very cool though! I haven't been able to convince anyone else of that yet, but I might dust off that patch and see how it could work with text objects. The idea is you could hold down ALT key (or Option on Mac), type a Unicode codepoint value (in regular Hex format), then release ALT and get that character. So hold down Alt, then enter "21e7", release it and get a ⇧ One thing I noticed today when looking at this is that we don't return a "not.def" (tofu) character when a glyph is not found in the current font for Text Objects. We just swallow it and return nothing, at least when copying and pasting. Showing tofu 𲎠 or replacement character � or maybe a character from our last resort font might help explain better what is going on.
Author
Member

I haven't been able to convince anyone else of that yet

I wonder why—that is, how do people enter exotic characters? Do they just not? :D
I use an extended keyboard layout so I rarely need it any more, but I used to use Windows with the default keyboard layout, and learned a bunch of alt codes just to compose (what I consider) proper French, because the default layout was just not enough.

One thing I noticed today when looking at this is that we don't return a "not.def" (tofu) character when a glyph is not found

Good point. My guess for this and other limitations would be that most people don’t first think of Blender when they need to typeset a piece of text. On a side note, I’m doing a project where I need to do just that, and more advanced typography would make my life so much easier right now, so you are not alone!

> I haven't been able to convince anyone else of that yet I wonder why—that is, how do people enter exotic characters? Do they just not? :D I use an extended keyboard layout so I rarely need it any more, but I used to use Windows with the default keyboard layout, and learned a bunch of alt codes just to compose (what I consider) proper French, because the default layout was just not enough. > One thing I noticed today when looking at this is that we don't return a "not.def" (tofu) character when a glyph is not found Good point. My guess for this and other limitations would be that most people don’t first think of Blender when they need to typeset a piece of text. On a side note, I’m doing a project where I need to do just that, and more advanced typography would make my life so much easier right now, so you are not alone!
Author
Member

(Probably no point in keeping this open if the menu is to be removed eventually.)

(Probably no point in keeping this open if the menu is to be removed eventually.)
Damien Picard closed this pull request 2023-04-04 22:32:19 +02:00
Member

I wonder why—that is, how do people enter exotic characters? Do they just not? :D

The main thought is that most people don't remember Unicode characters. So if they have to look them up online anyway ("google Unicode arrows") then they might as well copy the character to the clipboard from there and just paste into Blender. And that is almost entirely correct, although I have memorized some and you normally can't find characters to copy from the Private Use Areas. But I also don't want us to add a feature where I am the only user of it. LOL.

I use an extended keyboard layout so I rarely need it any more, but I used to use Windows with the default keyboard layout, and learned a bunch of alt codes just to compose (what I consider) proper French, because the default layout was just not enough.

This needs some clarification. I'm guessing that this did not involve remembering any Unicode codepoints ("U+" notation), but Windows Alt keys? Things like Alt+130 for é and Alt-144 for É? Those are things that many people have memorized.

At one point I did have all of those in the codepoint entry patch but took them out. It supported both the full set you get with Alt+1 (☺) - Alt+254 (■) and also the different set you get when you start with zero, alt-0199 (Ç) - alt-0240 (ð). It seemed even less likely to be accepted but might have to give that a think - and would also require the equivalent Mac ones too. Linux doesn't quite do this but does have some "compose" sequences.

> I wonder why—that is, how do people enter exotic characters? Do they just not? :D The main thought is that most people don't remember Unicode characters. So if they have to look them up online anyway ("google Unicode arrows") then they might as well copy the character to the clipboard from there and just paste into Blender. And that is almost entirely correct, although I have memorized some and you normally can't find characters to copy from the Private Use Areas. But I also don't want us to add a feature where I am the only user of it. LOL. > I use an extended keyboard layout so I rarely need it any more, but I used to use Windows with the default keyboard layout, and learned a bunch of alt codes just to compose (what I consider) proper French, because the default layout was just not enough. This needs some clarification. I'm guessing that this did not involve remembering any Unicode codepoints ("U+" notation), but Windows Alt keys? Things like Alt+130 for é and Alt-144 for É? Those are things that many people have memorized. At one point I did have all of those in the codepoint entry patch but took them out. It supported both the full set you get with Alt+1 (☺) - Alt+254 (■) and also the different set you get when you start with zero, alt-0199 (Ç) - alt-0240 (ð). It seemed even less likely to be accepted but might have to give that a think - and would also require the equivalent Mac ones too. Linux doesn't quite do this but does have some "compose" sequences.
Author
Member

The main thought is that most people don't remember Unicode characters.

Can’t blame them! :D
I admit I find it a terrible interface, especially if your memory is not great (not limited to Unicode, but all inputs using codes).

you normally can't find characters to copy from the Private Use Areas. But I also don't want us to add a feature where I am the only user of it. LOL.

That’s quite niche indeed!

I'm guessing that this did not involve remembering any Unicode codepoints ("U+" notation), but Windows Alt keys?

That’s right, I probably didn’t know about Unicode codepoints at the time.

Things like Alt+130 for é and Alt-144 for É?

I was very fond of « Alt-0171 and Alt-0187 », myself.

At one point I did have all of those in the codepoint entry patch but took them out.

I would have found it very nice to have at one point, but I don’t use those any more. Come to think of it, I’m not sure I know many people who do, or how useful a feature it would be. I reckon it’s the kind of thing that a few people sorely miss, and that the majority is completely oblivious to!

> The main thought is that most people don't remember Unicode characters. Can’t blame them! :D I admit I find it a terrible interface, especially if your memory is not great (not limited to Unicode, but all inputs using codes). > you normally can't find characters to copy from the Private Use Areas. But I also don't want us to add a feature where I am the only user of it. LOL. That’s quite niche indeed! > I'm guessing that this did not involve remembering any Unicode codepoints ("U+" notation), but Windows Alt keys? That’s right, I probably didn’t know about Unicode codepoints at the time. > Things like Alt+130 for é and Alt-144 for É? I was very fond of « Alt-0171 and Alt-0187 », myself. > At one point I did have all of those in the codepoint entry patch but took them out. I would have found it very nice to have at one point, but I don’t use those any more. Come to think of it, I’m not sure I know many people who do, or how useful a feature it would be. I reckon it’s the kind of thing that a few people sorely miss, and that the majority is completely oblivious to!
Damien Picard deleted branch dp_font_special_characters 2023-04-06 20:47:04 +02:00

Pull request closed

Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#106240
No description provided.