Recent

Author Topic: Automatic font change  (Read 40533 times)

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: Automatic font change
« Reply #60 on: December 08, 2016, 04:14:17 pm »
My question is whether the 20A suffix might make them perform better, and if so, is there a function that will format Unicode input as ANSI code to match the 20A parameter? It is only a question on my part, and I assume that you are the best person to present it to.
This is unlikely.
I cannot say for sure, since there's RichEdit is not open source, but I doubt that Microsoft are maintaining two versions of code Ansi vs Unicode.
Instead -A classes would act as wrapping over -W classes. Just by converting any Unicode characters into applicable Ansi characters.

So I don't expect usage of 20A will make the component to act better in anyway.

Even more, I'd recommend usage of A component only if anyone is developing for Win9x, where unicode support is an addition to the system.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #61 on: December 08, 2016, 04:35:19 pm »
Very good. Thanks for informing me. As is, Using the non-unicode font for English is still working... no Font Binding.

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: Automatic font change
« Reply #62 on: December 08, 2016, 04:46:19 pm »
I'm glad it's working for you.
How about sharing some screenshots Unicode fonts vs Non-Unicode fonts (indicating where the error occurs with Unicode fonts).
Something to put on the wiki, in case anyone else runs into the same issue.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #63 on: December 10, 2016, 05:33:17 pm »
Yes, I can post something that shows the behavior.

But I have found that my changing only the English font doesn't resolve things completely. Just yesterday, and after about twenty reloads, MSFTEDIT kicked in and changed about 30% of the English characters.

I am going to go to symbol fonts for everything... and I can only hope that it will cause RichEdit to leave things alone. It is my idea that using Unicode causes MSFTEDIT to do Font Binding. I have found numerous complaints about Font Binding on the Internet, and I have assumed that it is all Unicode related.

RichEdit does this with out respect to a font's quality. It does it with the standard fonts that are packaged with the Microsoft system. When I enter English text I don't do any manipulations to the keyboard, and when I do so for the other languages, I only change the key code... no RTF inserts.

Font Binding behaves very much like a computer virus. It monitors your behavior, and at some point it activates. That my document was fine until about the 20th time it was loaded is evidence that Font Binding is unpredictable (on my part) and very difficult circumvent. Once it even switched fonts on a complete paragraph that was in English. Yet sometimes it attacks Greek as well. Oddly as well, it has never messed with the Hebrew or Syriac (and the same developer had built both the Hebrew and Greek fonts).

In my opinion, RichEdit is unmarketable for Unicode applications with mixed languages. By unmarketable I mean... my application couldn't be given away at no cost. No one could rely on its product. Even if their document looked good, they wouldn't know that someone on another computer would see the same fonts (even if they used your program). You can't even be confident that they will see the same language. Nevertheless, I hadn't intended to sell it. I have always planned to give it away to everyone.

RichEdit with Unicode is only reliable if your entire document is one language and one font... and it is only on account of Font Binding.

The following is a typical post that I found on an Internet blog.

Quote
Andrew West on 11 Jul 2007 7:45 AM:

There are a couple of reasons why I personally think that an option to show characters with fallback/substitution/linking applied would not be such a cool idea.

Firstly, I'm sure that I am not the only person who loathes the way Microsoft's font substitution works. When I select a specific font to render my text with then what I really want is the application to respect my choice of font and not act as if it knows better then me and use some different font.

For example, in Notepad or Word if I select Code2000 to display some Syriac text it will be displayed with Estrangelo Edessa and there is no way I can get it to use Code2000 even though Code2000 supports Syriac just as well as Estrangelo Edessa does (and even worse in Word the font dropdown box shows Code2000 as the selected font when you click on the text, deceiving users into thinking that they have successfully
applied the font to the text when they haven't). If there was a registry setting where the user could define the font to use as a fallback for each script (or if there was an option to disable font substitution at the application level) then it wouldn't be so bad, but as it is, from a user's perspective the font substitution behaviour is unpredictable and often unwanted.

Secondly, font substitution behaviour is application-specific. Microsoft apps such as Word and Notepad do apply font substitution and linking, but many non-Microsoft apps such as OpenOffice.org and BabelPad do not. Thus if charmap showed characters with fallback/substitution/linking applied this would not necessarily be what you will get if you select the same font in some other application.

Incidentally, when you told us in September (http://blogs.msdn.com/michkap/archive/2006/09/03/737553.aspx) that charmap on Vista would still not display anything beyond the BMP and would still only display the
very limited list of Unicode blocks (nothing beyond Unicode 2.0 for @%#'$ sake !!!) I was stunned. How hard could it possibly be to update charmap to show everything up to and including Unicode 5.0 ?

So I think that a far more useful feature for charmap would be the ability to display all currently defined Unicode characters.

His remark about the font changing, but the font box still shows it by the original name, is also something that I have experienced. It's a sanctioned virus.

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: Automatic font change
« Reply #64 on: December 10, 2016, 06:16:55 pm »
His remark about the font changing, but the font box still shows it by the original name, is also something that I have experienced. It's a sanctioned virus.
Well, this is not a virus. This is an intentional behavior of the system.
i don't want to go into details, if it's good or bad, if an actual rendering font might be different from an actual font selected  (i.e. current FCL-PDF package has to deal with the problem, when rendering text).

But Microsoft provides a low-level API named DirectWrite (Win7+), which succeeded Uniscribe (WinXP+, Win9x).
AFAIK, either APIs allows the control over the font substitution (i.e. system suggests default font setup, a programmer has control over it - such as choosing a different font). 

What that means? It is **possible** to create your own editor, with a full control of how fonts are being rendered (and thus avoiding all the issues that RichEdit exposes).
But it's quite an expensive task.

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #65 on: December 10, 2016, 06:24:01 pm »
Here are the screen shots. There are two sets of proper and binding images.

Set #1 shows that parts of the Greek text have been swapped to both Arabic and Symbol fonts, and sections of the Sans Serif English font has been changed to Times Roman.

Set#2 shows that the single font for a Greek Paragraph has been randomly garbaged with Arabic. Every now and then a Greek character is left alone.

Due to their size I have send them one at a time.

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #66 on: December 10, 2016, 06:29:26 pm »
Even one image is too big. I'll have to resize the images.

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #67 on: December 10, 2016, 09:10:37 pm »
First group of images

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #68 on: December 10, 2016, 09:11:25 pm »
Second group of images

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #69 on: December 10, 2016, 09:20:28 pm »
What is expensive about DirectWrite? Isn't it part of the Win7+ systems? I have to say, "What a great fix"! They don't fix what they did... they just offer something different if you upgrade.

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: Automatic font change
« Reply #70 on: December 10, 2016, 09:35:00 pm »
DirectWrite or Uniscribe are free and ready, but creating a rich text editor based of them might be time consuming.

Take RichEdit as an example - 20 years in production, yet far from perfect

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #71 on: January 11, 2017, 09:50:11 pm »
There has been a breakthrough.

Google has built a large array of ancient fonts for both religious and linguistic use. They call them Google Noto Fonts.

https://www.google.com/get/noto/

Each language has its own font, and does not include any other language. Each font is indexed to a fallback font (Noto Sans) that is English. It currently contains English, Greek, and symbols. It has every character that Richedit wants, and all of the fonts share the same metrics, which Richedit also likes.

Richedit will go to that font for anything that is not in the other language fonts. Which means that Richedit will not do any font substitutions... and it is working.

In Google's own words... The name "noto" is to convey the idea that Google’s goal is to see “no more tofu” (no'to).

I assume that none of them are vegetarians.

The fonts are done well. But I wish that their Hebrew vowels were a bit larger. I have to squint to see them... but at least I see them every time I open the file.

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: Automatic font change
« Reply #72 on: January 11, 2017, 10:42:26 pm »
Quote
In Google's own words... The name "noto" is to convey the idea that Google’s goal is to see “no more tofu” (no'to).

I assume that none of them are vegetarians.

               

https://i.stack.imgur.com/RmHYK.jpg

https://i.stack.imgur.com/LdjiI.png

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #73 on: January 12, 2017, 01:45:28 pm »
lainz,

Succinctly put. Tofu, and it is humor... as is my own reference to vegetarianism.

But the gain for us by Google's elimination of tofu on the Internet is that Richedit does not do Font Binding in RichMemo. Google's method is operational in both of our worlds.

No one before Google has had the interest or resources to build a complete multi-language family of fonts. Others have done a few fonts, and they have not unified their database and metrics... so they have always been subject to Font Binding by RichEdit.

Even the system fonts that Microsoft has supplied for Unicode have not been structured to the precision that Google has implemented.

Rick
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #74 on: January 13, 2017, 08:37:22 pm »
I have done multiple loads and edits from a WinXP desktop, a WinXP laptop, and Win10 laptop (which has more capacity than either of the former) and there has been no fault in performance. I presume that the issues with Font Binding have been resolved.

Rick
« Last Edit: January 14, 2017, 09:56:46 pm by rick2691 »
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

 

TinyPortal © 2005-2018