Lazarus

Programming => Packages and Libraries => RichMemo => Topic started by: rick2691 on October 19, 2016, 08:45:14 pm

Title: Automatic font change
Post by: rick2691 on October 19, 2016, 08:45:14 pm
My effort to match font metrics by choosing compatible fonts failed. With one line it worked, but after doing several it failed.

Researching I found there is a function to turn off font swapping. Unfortunately RichMemo doesn't appear to have full functionality with the process.

It involves EM_GETLANGOPTIONS and EM_SETLANGOPTIONS, which also requires the parameter of IMF_AUTOFONT. The IMF_AUTOFONT parameter is what seems to be missing.

With that parameter... PageMemo.Perform(EM_SETLANGOPTIONS, 0,
                       LPARAM(PageMemo.Perform(EM_GETLANGOPTIONS, 0, 0)
                       and (not IMF_AUTOFONT))); 
...is supposed to work.

Alternately... //turn off richedit's auto font switching...
      i := SendMessage(PageMemo.Handle, EM_GETLANGOPTIONS, 0, 0);
      i := i and not IMF_AUTOFONT;
      SendMessage(PageMemo.Handle, EM_SETLANGOPTIONS, 0, i); 
...is also supposed to work.

But RichMemo does not have IMF_AUTOFONT registered.

A link to show how the parameter is managed is in... http://www.diicode.com/code/esijxny9-1257602

Can you look into it for me?

Rick
Title: Re: Automatic font change
Post by: skalogryz on October 19, 2016, 09:20:26 pm
sure. tonight EST.
Title: Re: Automatic font change
Post by: skalogryz on October 20, 2016, 06:17:55 am
Here's a sample.

Code: Pascal  [Select]
  1. const
  2.   IMF_AUTOKEYBOARD                  = $0001;
  3.   IMF_AUTOFONT                        = $0002;
  4.   IMF_IMECANCELCOMPLETE   = $0004;      // high completes the comp string when aborting, low cancels.
  5.   IMF_IMEALWAYSSENDNOTIFY = $0008;
  6.  
  7. procedure TForm1.Button1Click(Sender: TObject);
  8. var
  9.   opt : LResult;
  10. begin
  11.   opt:=SendMessage(RichMemo1.Handle, EM_GETLANGOPTIONS, 0, 0);
  12.   opt:=opt and not IMF_AUTOFONT; // disable autofont
  13.   SendMessage(RichMemo1.Handle, EM_SETLANGOPTIONS, 0, LParam(opt));
  14. end;  
  15.  
Title: Re: Automatic font change
Post by: rick2691 on October 20, 2016, 02:59:57 pm
I am posting an entire code section, in case there is a problem with where I am executing the code.

There is an odd behavior... when doing English in a mixed language line, any punctuations are stepping backwards as if it thinks that I am attempting to resume Hebrew. If I hit an English key it repositions to the proper English placement. This is the same behavior that Hebrew writing was doing with punctuations.

I assume that the constants may have some wrong values.

Besides this problem, the first objective has failed, it is not turning font swapping off.

Isn't EM_GETLANGOPTIONS returning a Byte value that represents a Set of operators?

I have wondered all along as to how...

opt:=opt and not IMF_AUTOFONT;

... could work. It may be a Delphi method. Likewise, isn't it testing for a true/false condition instead of a value?

One programmer I found had commented... "And for Lister's TRichEdit this flag is set by default (flags=0x83), but when I've removed it (set flags to 0x82), layout didn't switch anymore!"

Code: Pascal  [Select]
  1. procedure TCmdForm.btnOpenClick(Sender: TObject);
  2. var
  3.   fs: TFileStream;
  4.   opt : LResult;
  5. const
  6.   IMF_AUTOKEYBOARD  = $0001;
  7.   IMF_AUTOFONT = $0002;
  8.   IMF_IMECANCELCOMPLETE = $0004;     // high completes the comp string when aborting, low cancels.
  9.   IMF_IMEALWAYSSENDNOTIFY = $0008;
  10. begin
  11.   OpenDialog1.Title:= 'Select File';
  12.   OpenDialog1.Filter:= 'Rich Files (*.rtf)|*.rtf|Text Files (*.txt)|*.txt';
  13.   OpenDialog1.FileName:= '';
  14.   if OpenDialog1.Execute then
  15.   begin
  16.     fs := nil;
  17.     try
  18.       BuildPageMemo; // starts new tab and adds untitled PageMemo
  19.       DiskName:= OpenDialog1.Filename;
  20.       FileLabel:= ExtractFileName(Diskname);
  21.       FilePath:= ExtractFilePath(Diskname);
  22.       FileType:= lowercase(ExtractFileExt(Diskname));
  23.  
  24.       // turn font substitution off...
  25.       opt:=SendMessage(PageMemo.Handle, EM_GETLANGOPTIONS, 0, 0);
  26.       opt:=opt and not IMF_AUTOFONT; // disable autofont
  27.       SendMessage(PageMemo.Handle, EM_SETLANGOPTIONS, 0, LParam(opt));
  28.  
  29.       if FileType='.rtf' then
  30.          begin
  31.          // Utf8ToAnsi is required for windows stream
  32.          try fs:= TFileStream.Create(Utf8ToAnsi(DiskName), fmOpenRead or fmShareDenyNone);
  33.              PageMemo.LoadRichText(fs);
  34.              PageMemo.Hint:= DiskName; //OpenDialog1.Filename;
  35.              finally
  36.              fs.Free;
  37.              end;
  38.          end;
  39.  
  40.       if FileType='.txt' then
  41.          begin
  42.          PageMemo.Lines.LoadFromFile(DiskName);
  43.          x:= pos('.',FileLabel);
  44.          if x>0 then TabLabel:=Copy(FileLabel,1,x-1);
  45.          FileType:= '.rtf';
  46.          PageMemo.hint:= FilePath+TabLabel+'.rtf';
  47.          showmessage('Text-File will save as a Rich-File');
  48.          SavePageTab;
  49.          end;
  50.  
  51.       x:= pos('.',FileLabel);
  52.       if x>0 then TabLabel:=Copy(FileLabel,1,x-1);
  53.       PageControl1.ActivePage.Caption:= TabLabel; //FileLabel;
  54.  
  55.       BackupPageTab(Self);
  56.       StatusBar1.SimpleText:= ' '+ExtractFilePath(PageMemo.Hint);  //PageMemo.Hint;
  57.     finally
  58.     end;
  59.   end;
  60. end;  
  61.  

Rick
Title: Re: Automatic font change
Post by: rick2691 on October 20, 2016, 03:17:00 pm
Here is the first introduction to turning off font swapping...

http://archives.miloush.net/michkap/archive/2006/02/13/531110.html

It's first form was in C++ (or another C thing)

Rick
Title: Re: Automatic font change
Post by: skalogryz on October 20, 2016, 03:39:03 pm

Isn't EM_GETLANGOPTIONS returning a Byte value that represents a Set of operators?

I have wondered all along as to how...

opt:=opt and not IMF_AUTOFONT;

... could work. It may be a Delphi method. Likewise, isn't it testing for a true/false condition instead of a value?
Yes, it is. But using bitwise operators is more straight forward way.
Besides, EM_GETLANGOPTIONS doesn't return byte, it returns LRESULT (which is 32-bit on 32-bit machines, and 64-bit on 64-bit machines).
Thus assuming it's byte, there's a potential risk of loosing data.

That's why I prefer to do low-level interaction via bitwise operations, rather than building "set of" type on top of it. (using "set of" with a high-level interface is 100% fine)
Title: Re: Automatic font change
Post by: rick2691 on October 20, 2016, 05:14:06 pm
What about the "odd behavior" that I cited on Reply #3, and that it had not turned off the font switching?

Rick
Title: Re: Automatic font change
Post by: skalogryz on October 20, 2016, 06:01:39 pm
What about the "odd behavior" that I cited on Reply #3, and that it had not turned off the font switching?
Remember, you've had a similar problem with spaces and commas.
When you wanted them to be Hebrew, RichMemo (richedit) put them as English.
Thus you added a special RTF insert, to force the language.

Is it possible that this code actually takes effect?
Title: Re: Automatic font change
Post by: rick2691 on October 20, 2016, 07:15:52 pm
I will check. But I just found that my English portion that I had cited was operating with a swapped font. That was why it was acting like that.

I checked the opt computation. It is EM_SETLANGOPTIONS sets it to 130. Your "and not IMF_AUTOFONT" code sets it to 128 ...so it is correct.

It must be that I am activating the "no switch" code at the wrong time, because it doesn't do anything.

But one programmer commented that RichEdit 3 had altered the EM_GETLANGOPTIONS method. He said he had to go back to version 2. When he did it operated fine. He did not specify what was changed. Do you think that our current version has assigned a different value to IMF_AUTOFONT.

Rick
Title: Re: Automatic font change
Post by: skalogryz on October 20, 2016, 07:23:40 pm
But one programmer commented that RichEdit 3 had altered the EM_GETLANGOPTIONS method. He said he had to go back to version 2. When he did it operated fine. He did not specify what was changed. Do you think that our current version has assigned a different value to IMF_AUTOFONT.
I'm thinking that the solution is very fragile.
It's not just going back to some version, it also depends on how this old-version is implemented for a certain system. That's quite a blackbox, and it's up to MS how things will work.
Title: Re: Automatic font change
Post by: rick2691 on October 20, 2016, 09:38:11 pm
The specifications, posted as follows, indicate that the options have values of 1 or 0 for being on or off respectively. Does that indicate that it is a string values for a set? But EM_GETLANGOPTIONS returns a single value, and it is 130... very large.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb788040(v=vs.85).aspx
Title: Re: Automatic font change
Post by: molly on October 20, 2016, 09:46:30 pm
But EM_GETLANGOPTIONS returns a single value, and it is 130... very large.
That is because the value returned is value that can consist of multiple flags. Those names listed all represent a bit (or bit combination) and as such are flags. Figure out which bit it is that you need and filter it from that return value.

e.g.
IMF_AUTOFONT = $2;

If returnvalue and IMF_AUTOFONT <> 0 then BitIsOn else BitIsOff

Or did i misunderstood what you did not understood ?  :)
Title: Re: Automatic font change
Post by: skalogryz on October 20, 2016, 09:52:33 pm
It's a bit mask. You can read about that in description of EM_SETLANGOPTIONS
"This message sets the values of all language option flags" (where a flag is a bit)

Values for each of the option (or a flag) comes in Richedit.h which is part of MSDN.
Pascal (obviously) is lagging behind and some constants might not be present in richedit.pas.

However, finding actual values is easy. you can simply google for "define IMF_DUALFONT" and it should bring you quickly to the latest RichEdit.h (i.e. here (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwi0kbGnkurPAhWHez4KHWptBtYQFgglMAE&url=http%3A%2F%2Fmath.nemcc.edu%2Fcourses%2Fcp2%2Fcpp%2Finclude%2FRichedit.h&usg=AFQjCNGeYFREOcdGVW_gRhPmZnLN8g3ESw&sig2=usfgGvUMb6FtTcYqFoBH7Q&cad=rja))

The value 130 means corresponds to hexidemical value $82. (I'm using dollar sign, since it's pascal convention)
And that corresponds to two flags:
IMF_AUTOFONT = $0002
IMF_DUALFONT = $0080
IMF_AUTOFONT or IMF_DUALFONT= $82=130
Bitwise operations.

Now, whenever you write an expression like this:
Code: [Select]
  opt:=opt and not IMF_AUTOFONT;
where opt originally is 130, what you get is the following:

not IMF_AUTOFONT is $FFFFFFFD (it's missing bit $2 )

$82 and $FFFFFFFD = $80  ($8 - matched, $2 didn't match)
That's how you end up with 128 (=$80).
Even though 128 might look a very high value... it's actually only 1 flag!
In the same way 130 is actually 2 flags... and so on.

"set ofs" are operating in the similar manner (as long as set is declared as a bitwise set)
Title: Re: Automatic font change
Post by: rick2691 on October 20, 2016, 10:31:22 pm
It looks like this is another dead horse. It is the stupidest thing that I have seen Microsoft do. Their own fonts don't look good, or they don't do 0 based vowels, or they don't do every language, or they don't handle diacritics properly... and they force us to use one font in an entire paragraph. If we try to use another, they switch it to one of their own wimpy fonts. They even swapped out a Greek font for an Arabic font.

My definition of a "control freak" is a person who insists on managing things, and has no clue as to how to do it.

Rick
Title: Re: Automatic font change
Post by: skalogryz on October 20, 2016, 10:35:48 pm
Try to take multilingual text to Wordpad. See how it behaves.

Purpose of such test:
Wordpad is pretty much how RichEdit behaves by default. It doesn't have richmemo on top as well as any of your code. It would also behave its best.

If it doesn't act the way you like, there's a slight chance, that you won't be able to make Richmemo to work.

Also. RichEdit might behave much better, if you install corresponding language layouts to your system, and would use them to type the text in.

This has been Microsoft policy for years - make it nice and easy for an end user. Not a developer :) (What makes sense to some extent)
Title: Re: Automatic font change
Post by: rick2691 on October 21, 2016, 01:24:10 pm
WordPad has no function for turning off font switching. Microsofts keyboard layouts are not unified for Semitic and Semitic based languages, which makes them difficult to learn.

The problem is not with my code. Half of it is your own. The functions that I have built are within the rules. I haven't forced anything. The problem is that Microsoft is withholding functionality. They have published RichEdit and RTF rules and functions, but they are not operational.

Rick

Title: Re: Automatic font change
Post by: rick2691 on October 21, 2016, 07:49:33 pm
I found some code in a unit for Delphi, so I am pretty confident that it works for that environment. RichMemo is processing (it doesn't kick anything back) but it is not having any effect. So what is it that is happening (rather, not happening)?

Code: Pascal  [Select]
  1. procedure TCmdForm.AutoKeyboardOff;
  2. var opt: LResult; // some do integer
  3. const
  4.   IMF_AUTOKEYBOARD        = $0001; // active by load file
  5.   IMF_AUTOFONT            = $0002; // active by default
  6.   IMF_IMECANCELCOMPLETE   = $0004; // high completes output on abort, low cancels ...not active
  7.   IMF_IMEALWAYSSENDNOTIFY = $0008; // active by default
  8. begin
  9. opt:= SendMessage(PageMemo.handle, EM_GETLANGOPTIONS, 0, 0); //showmessage('kbd get: '+inttostr(opt));
  10. if ((opt and IMF_AUTOKEYBOARD)<>0) then Dec(opt, IMF_AUTOKEYBOARD);
  11. SendMessage(PageMemo.handle, EM_SETLANGOPTIONS, 0, LPARAM(opt)); //showmessage('kbd set: '+inttostr(opt));
  12. end;
  13.  
  14. procedure TCmdForm.AutoFontOff;
  15. var opt: LResult; // some do integer
  16. const
  17.   IMF_AUTOKEYBOARD        = $0001; // active by load file
  18.   IMF_AUTOFONT            = $0002; // active by default
  19.   IMF_IMECANCELCOMPLETE   = $0004; // high completes output on abort, low cancels ...not active
  20.   IMF_IMEALWAYSSENDNOTIFY = $0008; // active by default
  21. begin
  22. // SendMessageW (Unicode) and SendMessageA (ANSI)
  23. // does not help to use SendMessageW, nor to invoke RichEdit.EM_
  24. opt:= SendMessage(PageMemo.handle, EM_GETLANGOPTIONS, 0, 0);  //showmessage('fnt get: '+inttostr(opt));
  25. if ((opt and IMF_AUTOFONT)<>0) then Dec(opt, IMF_AUTOFONT);
  26. SendMessage(PageMemo.handle, EM_SETLANGOPTIONS, 0, LPARAM(opt));  //showmessage('fnt set: '+inttostr(opt));
  27. end;
  28.  

Rick
Title: Re: Automatic font change
Post by: skalogryz on October 21, 2016, 08:32:13 pm
just do this :)
Code: Pascal  [Select]
  1.   SendMessage(PageMemo.handle, EM_SETLANGOPTIONS, 0, 0);
  2.  
Title: Re: Automatic font change
Post by: rick2691 on October 22, 2016, 01:15:24 pm
Quote
SendMessage(PageMemo.handle, EM_SETLANGOPTIONS, 0, 0);

No, it does not respond to a 0,0 setting. The communication just isn't there.

One amendment... EM_GETLANGOPTIONS did report that it was set to 0.

Rick
Title: Re: Automatic font change
Post by: rick2691 on October 22, 2016, 03:26:05 pm
OK. I have not been able to disable font switching, but I have found a way to avoid it.

What I have been doing is posting a table (by tabbing) of keyboard keys and resulting language display results.

The remedy is to activate English, type, tab, then activate Hebrew, type, and activate English and tab.

Before, I had been staying in Hebrew for the Tab, and the same for Syriac and Greek.

By making sure that I was wrapping the characters in English tabs had caused RichEdit to not switch the fonts.

The same would apply to start & ending spaces and the same with punctuations. They need to be typed in your dominant language.

It is a tedious operation if you are trying to write a Keyboard Manual, but it minimally helps with my current sanity.

Please don't let this be a reason to forget about the problem... "autofont" needs to be disabled. Without "autofont" a user can type freely without tedious rules.

Rick

Title: Re: Automatic font change
Post by: rick2691 on October 24, 2016, 03:35:34 pm
My system has Msftedit.dll, Richedit20.dll, and Richedit32.dll

You have previously posted that RichMemo opts for Msftedit.dll first, and uses Richedit20.dll if it is absent. Would there be a way to have it use Richedit20.dll first?

It may be that the misfunctions that I encounter are due to Msftedit.dll

To test it I tried to remove Msftedit.dll from my system, but the system just reinstalled it.

Rick
Title: Re: Automatic font change
Post by: skalogryz on October 24, 2016, 03:41:00 pm
To test it I tried to remove Msftedit.dll from my system, but the system just reinstalled it.
please don't do such horrible things to your system :) it doesn't deserve it.

Instead change the code in Win32RichMemoProc.pas.
Find InitRichEdit function and comment out Msftedit.dll usage code like this:
Code: Pascal  [Select]
  1. function InitRichEdit: Boolean;
  2. begin
  3.   if GlobalRichClass = '' then begin
  4.     {if LoadLibrary('Msftedit.dll') <> 0 then begin
  5.       GlobalRichClass := 'RichEdit50W';
  6.     end else} if LoadLibrary('RICHED20.DLL') <> 0 then begin
  7.       if UnicodeEnabledOS then GlobalRichClass := 'RichEdit20W'
  8.       else
  9.       GlobalRichClass := 'RichEdit20A'
  10.     end else if LoadLibrary('RICHED32.DLL') <> 0 then begin
  11.       GlobalRichClass := 'RichEdit';
  12.     end;
  13.      
  14.     if not Assigned(RichEditManager) then
  15.       RichEditManager := TRichEditManager;
  16.      
  17.     Result := GlobalRichClass <> '';
  18.   end;
  19. end;
  20.  

I was planning to add explicit dll and richedit class selection for Windows.
But for whatever reason it was not completed.
Title: Re: Automatic font change
Post by: skalogryz on October 24, 2016, 04:38:41 pm
I was planning to add explicit dll and richedit class selection for Windows.
But for whatever reason it was not completed.
and now it is done - r5289 allows to override richedit's class used by RichMemo.

Naturally, with the class overridden the proper .dll loading is now a responsibility of the user's code.
Title: Re: Automatic font change
Post by: rick2691 on October 24, 2016, 05:48:22 pm
How do I set the class?
Title: Re: Automatic font change
Post by: skalogryz on October 24, 2016, 05:56:22 pm
How do I set the class?
You need to use the latest revision.
Add "Win32RichMemo" to your uses section. The unit exposes RichEditClass variable, you need to assign a value to it.
Please note that the class might require you to load a specific .DLL version. (you should be able to find the listing of versions + class names + dlls on MSDN (https://msdn.microsoft.com/en-us/library/windows/desktop/bb787873(v=vs.85).aspx). MSDN gives the class name as "RICHEDIT_CLASS" it's not an actual string, but rather a constant name in MSDN headers. To find the actual string you should google for "define RICHEDIT_CLASS"
which might look like this:
Code: [Select]
/* Richedit2.0 Window Class. */

#define RICHEDIT_CLASSA "RichEdit20A"
#define RICHEDIT_CLASS10A "RICHEDIT" // Richedit 1.0

#ifndef MACPORT
#define RICHEDIT_CLASSW L"RichEdit20W"
#else /*----------------------MACPORT */
#define RICHEDIT_CLASSW TEXT("RichEdit20W") /* MACPORT change */
#endif /* MACPORT  */

#if (_RICHEDIT_VER >= 0x0200 )
#ifdef UNICODE
#define RICHEDIT_CLASS RICHEDIT_CLASSW
#else
#define RICHEDIT_CLASS RICHEDIT_CLASSA
#endif /* UNICODE */
#else
#define RICHEDIT_CLASS RICHEDIT_CLASS10A
#endif /* _RICHEDIT_VER >= 0x0200 */
)

Here's an example:
Code: Pascal  [Select]
  1. uses
  2.   Windows .... , Win32RichMemo;
  3.  
  4.  
  5. procedure TForm1.FormCreate(Sender: TObject);
  6. begin
  7.   LoadLibrary('RICHED32.DLL'); // loading the dll
  8.   RichEditClass := 'RichEdit20W'; // specifying the class
  9. end;
  10.  
  11.  
That's it. Make sure you specify the class and load the library before a RichMemo is actually created.
FormCreate() method is fine. You could also put the code into "initialization" section of your unit.
Title: Re: Automatic font change
Post by: rick2691 on October 24, 2016, 06:32:29 pm
I am looking at r5289. It doesn't have anything in it for RichEdit20W or RICHEDIT_CLASSW nor anything called for in your post.

To be clear... with the entries:

LoadLibrary('RICHED32.DLL'); // loading the dll
RichEditClass := 'RichEdit20W'; // specifying the class

Isn't RICHED32.DLL for RichEdit version 1? Wouldn't I want to try RICHED20.DLL first?
Title: Re: Automatic font change
Post by: rick2691 on October 24, 2016, 06:52:49 pm
Also, should I still do those edits to Win32RichMemoProc?
Title: Re: Automatic font change
Post by: skalogryz on October 24, 2016, 07:31:39 pm
I am looking at r5289. It doesn't have anything in it for RichEdit20W or RICHEDIT_CLASSW nor anything called for in your post.
The change itself is to make win32 implementation more dynamic, so any class could be used.
So don't except to see RichEdit20W or RICHEDIT_CLASSW there.

Isn't RICHED32.DLL for RichEdit version 1? Wouldn't I want to try RICHED20.DLL first?
You're right, you should try RICHED20.DLL first

Also, should I still do those edits to Win32RichMemoProc?
No, please revert any changes made to Win32RichMemoProc.
Title: Re: Automatic font change
Post by: rick2691 on October 24, 2016, 08:08:17 pm
Done deal. I'll try it out.
Title: Re: Automatic font change
Post by: rick2691 on October 24, 2016, 08:14:22 pm
raised exception win32richmemo line 494

I had used...

LoadLibrary('RICHED20.DLL');  // loading the dll  // 'RICHED32.DLL'
 RichEditClass := 'RichEdit20W'; // specifying the class
Title: Re: Automatic font change
Post by: skalogryz on October 24, 2016, 08:20:45 pm
raised exception win32richmemo line 494
makes sense. r5290 fixes the issue.
Title: Re: Automatic font change
Post by: rick2691 on October 24, 2016, 09:41:58 pm
Guess What? As best I can tell from loading existing files it does not switch fonts!

I'll have to type a new file in order to be certain.

However, it does not like my Syriac fonts at all! It won't post them as Right-to-Left, and with some files it displays garbage. I hope that the issues isn't that the Syriac is using formatting that has been developed after the RICHED20.dll, and it just can't do it.

English, Greek, and Hebrew are just fine. No swapping.

Rick

Title: Re: Automatic font change
Post by: rick2691 on October 25, 2016, 04:41:30 pm
On attempting to switch back to MSFTEDIT for a test it raised an exception...

error 1407
file win32wcontrols.pp
line 253

code used...

LoadLibrary('MSFTEDIT.DLL'); //  'RICHED32.DLL'  'RICHED20.DLL'  'MSFTEDIT.DLL'
RichEditClass:= 'RichEdit20W'; // specifying the class 

Rick
Title: Re: Automatic font change
Post by: skalogryz on October 25, 2016, 05:50:21 pm
On attempting to switch back to MSFTEDIT for a test it raised an exception...

code used...

LoadLibrary('MSFTEDIT.DLL'); //  'RICHED32.DLL'  'RICHED20.DLL'  'MSFTEDIT.DLL'
RichEditClass:= 'RichEdit20W'; // specifying the class 
The combination of .dll and the class name doesn't exist. The proper class name is RichEdit50W

But, if you want to go back to MSFTEdit.dll, then just remove these lines.
Title: Re: Automatic font change
Post by: rick2691 on October 25, 2016, 09:25:07 pm
Using RichEdit50W is adequate for what I am doing. I am testing Syriac fonts. At present I have not found one that works with RICHED20.DLL

It looks like I have lost Syriac. Depressing. The MSFTEDIT behavior was unacceptable.

Rick
Title: Re: Automatic font change
Post by: rick2691 on October 26, 2016, 06:50:30 pm
I tracked down the problem. RICHED20.DLL was built prior to Syriac entering the Unicode system. Since its index values are higher than what existed at the time of RICHED20.DLL, it refuses to access them... another "better idea" by Microsoft.

I will either have to abandon Syriac (and any other recent additions to Unicode), or revert to an ASCII simulation of the language (where glyphs are assigned to the ASCII character set). If I do the latter I will have manage the right-to-left process (and the complexity of a scripting font) independently of the DLL.

Rick
Title: Re: Automatic font change
Post by: rvk on October 26, 2016, 07:16:39 pm
I tracked down the problem. RICHED20.DLL was built prior to Syriac entering the Unicode system. Since its index values are higher than what existed at the time of RICHED20.DLL, it refuses to access them... another "better idea" by Microsoft.

What RICHED20.DLL are you taking about? There are a lot of versions (and sub-versions).

v5.30.23.1230 (included with Windows XP)
v5.31.23.1229 (included with Windows 7)
v5.40.11.2210 (installed with Office XP)
v5.50.99.2050 (installed with Office 2003)
v12.0.4518.1014 (installed with Office 2007)
v14.0.4750.1000 (installed with Office 2010)
v15.0.4420.1017 (installed with Office 2013)
v16.0.6925.1014 (installed with Office 2016)

And each main-version has sub-versions which have subtle differences. But RICHED20.DLL is still maintained.

There are a few more versions I didn't mention.
So just saying that RICHED20.DLL doesn't work, doesn't mean all versions don't work.
Title: Re: Automatic font change
Post by: rick2691 on October 26, 2016, 09:02:32 pm
I assume it is what came with XP, because I never load it. How do you obtain the new versions?
Title: Re: Automatic font change
Post by: rick2691 on October 26, 2016, 10:03:46 pm
Mine is... version 5.30.23.1230
Rich Text Edit Control, v3.0
Copyright © Microsoft Corp. 1997-1999
Title: Re: Automatic font change
Post by: rvk on October 26, 2016, 10:26:34 pm
I also have/had a lot of trouble finding a good RICHED20.DLL for my purposes. When I found one that works correctly with a certain feature it gave me trouble with another one. Ultimately I settled with a version 3.1 subversion 5.31.23.1230 (which came with a update in Windows 7 or 8 ).

To give you an indication of the versions I tried (for my needed feature-set, which might be different for you) here is my RICHED20 directory with different versions:

Code: [Select]
How to prevent crashes when pasting into the text editor - Kinook Software Forums.url
MSFTEDIT - (v7.5) 10.0.10240.16386.dll
Probleem-versies.txt
RICHED20 - (v3.0) 5.30.23.1230 (winXP).DLL
RICHED20 - (v3.1) 5.31.23.1229 (win7).DLL
RICHED20 - (v3.1) 5.31.23.1230.DLL
RICHED20 - (v3.1) 5.31.23.1231 (win10).DLL
RICHED20 - (v4.0) 5.40.11.2210 (OfficeXP).DLL
RICHED20 - (v5.0) 5.50.99.2050 (Office2003).DLL
RICHED20 - (v6.0) 12 MSPTLS.DLL
RICHED20 - (v6.0) 12.0.6606.1000.DLL
RICHED20 - (v6.0) 14 MSPTLS.DLL
RICHED20 - (v6.0) 14.0.4750.1000.DLL
RICHED20 - (v8.0) 15 MSPTLS.DLL
RICHED20 - (v8.0) 15.0.4420.1017 (b) msptls.dll
RICHED20 - (v8.0) 15.0.4420.1017 (b).DLL
RICHED20 - (v8.0) 15.0.4420.1017.DLL
RICHED20 - (v8.0) 15.0.4659.1000.DLL
So you could try the 5.4, 5.5 or even 12 through 15 versions.

You can take some of the versions from Office or later Windows-versions.
I think versions above 12 need MSPTLS.DLL too but below that only RICHED20.DLL is needed.
You can also download some of these here (the >12 have MSPTLS.DLL also included):
http://www.kinook.com/Forum/showthread.php?t=2853

You can see that the version you've got (5.30.23.1230) is a very old one (XP) and even 3.0 at that. I would certainly go for at least a 5.31.x version (which should still work on XP). Just copy the RICHED20.DLL to your .exe directory and it will be used. If the 5.31 doesn't have the feature you need you can go to the higher versions until you get the right one :)

Yeah... picking the right one was a real challenge because in some versions certain bugs where introduced which where solved in earlier versions... but if you don't use certain things you might nog even encounter these bugs.

Also the absolute last version might not work on XP anymore but you can test that yourself.
Title: Re: Automatic font change
Post by: rick2691 on October 27, 2016, 02:35:35 pm
I have found that my system will not permit me to install different versions for MSFTEDIT and RICHED20. It lets me copy/paste and overwrite, but then it politely reinstalls the original version without giving any notice.

Rick
Title: Re: Automatic font change
Post by: rvk on October 27, 2016, 02:50:36 pm
I have found that my system will not permit me to install different versions for MSFTEDIT and RICHED20. It lets me copy/paste and overwrite, but then it politely reinstalls the original version without giving any notice.
You don't have to install/reinstall RICHED20.DLL. You can just put it in the .exe directory (with your program) and it will be loaded. The program directory has priority over the C:\WINDOWS\SYSTEM32 or any other directory.

It's how I supply the RICHED20.DLL with my program because each Windows-version has another version with those subtle differences that you can't really count on the system-provided one.
Title: Re: Automatic font change
Post by: rick2691 on October 27, 2016, 02:54:06 pm
I'll try it. Thank you for your advice.
Title: Re: Automatic font change
Post by: rick2691 on October 27, 2016, 03:47:15 pm
OK. I went through every combination and found the same results. The oldest RICHED20 is the only one that does not swap fonts, and it cannot work with the Syriac font. All of the MSFTEDIT's will swap fonts, and they cannot be turned off.

Rick
Title: Re: Automatic font change
Post by: rvk on October 28, 2016, 10:45:27 am
Note that Segoe UI Historic does include Syriac (added in Windows 10).
Title: Re: Automatic font change
Post by: rick2691 on October 28, 2016, 02:50:07 pm
It isn't an issue of whether a font contains Syriac. The problem is that the RICHED20 file that will constrain "font switching" will not access the Syriac font. It is because Syriac was not a part of the Unicode system when the particular XP RICHED20 was built.

All of the modern RICHED20 and MSFTEDIT files (including the MSFTEDIT that came default with XP) can work with Syriac... but "font switching" is unacceptable for me.

Rick
Title: Re: Automatic font change
Post by: rick2691 on November 20, 2016, 08:41:15 pm
I have spent much time at researching the Font-Binding problem. It has been an aggressive method since Richedit version 3, and had begun with version 2. It is systematic and cannot be overcome. The EM_LANGOPTIONS code is disabled. Doing so they declared war on Unicode, and fully intend to acquire its demise.

The result is that RichEdit is worthless for Unicode. HTML is worthless as well, because they have influenced it in the same way... though HTML does have to deal with single font ASCII. Yet this conflict is why professional editors do not use Unicode. Microsoft has over thought the issues, and turned their baby into crap.

As is, I have to rely on the Riched20 DLL's. They cannot recognize Syriac as right-to-left. I can overcome that element until it comes to wrapping. I cannot override Richedit wrapping... and it wraps it as English. In contrast, the MSFTEDIT is useless. It ignores every RTF rule, and uses heuristic algorithms as if it is dealing with an ASCII (single font) editor.

My conclusion is that the editor is fine for left-to-right writing. But nothing more. If you do Greek, it will bring in WingDings for its font. If you do Hebrew, it will use the Hebrew font for its English (its English characters).

At least with the 20 DLL it will keep your assigned fonts, and it works for Hebrew and English, but nothing more. It also does WingDing Greek. Unicode is just crap. RichEdit is an English fettered wimp.

Rick
Title: Re: Automatic font change
Post by: skalogryz on November 21, 2016, 03:01:02 am
Hey Rick,

Thank you for doing the research.
However, I've a couple questions:
* did you make a test with an actual hebrew/arabic input (keyboard layouts) installed in the system? I'm suspecting that RichEdit control might start behaving differently with the text actually entered from keyboard.
* did you make a test on a system with hebrew or arabic language selected as primary language of the system? (in days of Win9x there has to be a special version of the system, however with WinXP such practice stopped)

Title: Re: Automatic font change
Post by: rick2691 on November 22, 2016, 06:19:12 pm
By things that I have read, I am not the first to have these problems. By the RichEdit Division it is what they do when a file is read from disk. They treat Unicode as maverick entries, and pay no attention to its RTF font assignments. They do this because you don't have to enter Unicode by an Editor method... you just type an Alt-Key and an index number (ie. ALT-1808).

As to a primary language, it never swaps with a dedicated page or paragraph. It only happens when you mix languages in a paragraph (a line is actually a paragraph).

I have found that most people have used the keyboard layout by their system. I am actually the oddball on that issue. Nevertheless, Font-Binding only happens with a disk read or copy/paste entry, and they just don't want you to mix fonts. They want you to operate as if it is an ASCII editor. The RichEdit creators have said so. Unicode is supposed to be One-Font.

I have also found that it is the Syriac font that is causing most of the issues. If I only do English, Hebrew, and Greek (omitting Syriac) it all works fine. Syriac uses a modern method that isn't on the 20 DLL's, and appears to be incomplete on the MSFTEDIT. It might be fixed for Windows 10, but I doubt it. I heard that Windows 9 never came to market because it could not do Unicode. They aren't great at fixing things.

My opinion is that RichEdit's operational premise is simply wrong-headed.

So, I don't think the key-layout is the answer... but I might break down and try it. My problem is that I am tired of trying things. My thinking is --if it is all me-- I wouldn't have found so many people complaining about it. Additionally, RichEdit has rarely responded to them, and when they did... it was just their own whining back about how difficult it is deal with Unicode.

I don't get it. It is RTF. Not Unicode. All they have to do is stick to RTF.

Rick
Title: Re: Automatic font change
Post by: rick2691 on November 22, 2016, 07:49:48 pm
I forgot to stress... they disabled the function that will turn off Font-Binding. They don't want us to rely on RTF.

Rick
Title: Re: Automatic font change
Post by: rvk on November 22, 2016, 07:57:13 pm
I forgot to stress... they disabled the function that will turn off Font-Binding. They don't want us to rely on RTF.
Do you have documentation of the fact that they "disabled" this function?

It could just be that, while doing some other programming to the component, a bug appeared which they are not aware of. The problem there is how to make the right people aware of this bug.

Just yelling that they disabled it and are working against some feature isn't going to fix it. Especially if it was done accidentally.
Title: Re: Automatic font change
Post by: skalogryz on November 23, 2016, 01:24:50 am
Rick,

I'm tempted to ask you for links where you found all this information.
I want to put up a disclaimer article on the wiki, so people would not expect too much from RichMemo (on Windows).

Also, while researching that, did you run into an alternative to RichEdit? some (open source) component that could be used for complex script text (such as Syriac) processing?
If you know or aware of any, I'm wondering I could put into RichMemo. (thus you wouldn't need to change any of your code you wrote so far)
Title: Re: Automatic font change
Post by: rick2691 on November 23, 2016, 03:54:57 pm
I haven't documented very much. I haven't been searching to "make a case" about things, only to find help on things. The best keywords for searching are "RichEdit Font Binding". The most useful information that I have found has been authored by "Murray Sargent", who appears to be a RichEdit spokes person.

I found a couple of blogs by Murray Sargent, and I left queries for him, but I have not seen a response to date. The blogs were old, had many queries and few responses. They have also been silent for a couple of years, so they may not be monitored any longer.

I have attached the best article that I have found by Murray Sargent.

As to their disabling the turn off function for Font Binding... it is only a deduction by its not working in any MSFTEDIT DLL's. The counter evidence is that, at earlier times, there are substantial posts on the Internet that attest to it being operational.

As to a replacement for RichEdit... only Kcontrols. It has a very different command structure. Given that it will take a good deal of rewriting, and I don't know what I would have after it is done, I have been doing all that can to stay with RichMemo. Quoting an old saying, "It's the devil that I know," at this point.

@RVK
Quote
Just yelling that they disabled it and are working against some feature isn't going to fix it. Especially if it was done accidentally.

You are right.

Rick
Title: Re: Automatic font change
Post by: rick2691 on November 27, 2016, 02:23:29 pm
I use "FreeCommander XE" by Marek Jasinski <marek@freecommander.com>, and I noticed that his file viewer does not use Font Binding. A few weeks ago I contacted Marek by email, and he told me that he uses an RTF previewer from ATViewer... http://atviewer.sourceforge.net/atviewer.htm.

By downloading the ATviewer resources, the viewer appears to be using SynEdit, or at least a version of it that is named ATSynEdit.

So perhaps SynEdit itself has a method for suppressing Font Binding.

Rick
Title: Re: Automatic font change
Post by: rick2691 on November 27, 2016, 03:22:25 pm
Glancing at ATviewer and some of SynEdit, they might be using a graphical display, similar to my PrintView procedures, but theirs may not use RichEdit for the metrics.

Rick
Title: Re: Automatic font change
Post by: rick2691 on November 30, 2016, 03:14:33 pm
An interesting change...

Both of the Murray Sargent blogs, that I had posted by, have removed my entries. They were the same, and were as follows:

Quote
I am building a Unicode editor that uses the MSFTEDIT.DLL. My application is for Biblical languages (English, Hebrew, Syriac, and Greek), and they need to be typed as mixed language paragraphs for comparison and explanation. The editor displays the mix with no malfunction, but when I save the file and load it again, it switches the fonts. Curiously the biggest issue is with a Unicode English font (Calibre), but it also happens with Greek texts. It will switch to the English in the first Non-English font that was used. By my objective this is unacceptable. The English font is named in the RTF file, and the font is present in the system folder… So why switch the font?

I have tried to eliminate this behavior by using the EM_SETLANGOPTIONS function. The following is how I have implemented this:

SendMessage(PageMemo.handle,EM_SETLANGOPTIONS,WPARAM(0),LPARAM((SendMessage(PageMemo.handle,EM_GETLANGOPTIONS,WPARAM(0),LPARAM(0)) and not(IMF_AUTOKEYBOARD))));

SendMessage(PageMemo.handle,EM_SETLANGOPTIONS,WPARAM(0),LPARAM((SendMessage(PageMemo.handle,EM_GETLANGOPTIONS,WPARAM(0),LPARAM(0)) and not(IMF_AUTOFONT))));

SendMessage(PageMemo.handle,EM_SETLANGOPTIONS,WPARAM(0),LPARAM((SendMessage(PageMemo.handle,EM_GETLANGOPTIONS,WPARAM(0),LPARAM(0)) and not(IMF_DUALFONT))));

The above procedures establish the settings, but they do not stop RichEdit from switching fonts.

Specifically I am using the RichMemo component by the Lazarus FreePascal compiler, and am operating on a Windows XP PRO SP3 computer. RichMemo serves as a wrapper for the MSFTEDIT DLL.

Can you help me with this issue?

Rick

For whatever the reason was, it looks like another dead horse to be reaching out to RichEdit representatives.

Rick
Title: Re: Automatic font change
Post by: Alextp on December 03, 2016, 03:14:27 am
Hello;
I made ATviewer, and want to say-
- it has 2 modes to show text+Unicode: a) self painting on canvas via ExtTextOut(..) or smth
 b) loading text into RichEdit (it is version which Delphi calls, 2.0 or 1.0 or 3.0, I dont know)

- ATviewer don't use Synedit, and ATSynedit too


Title: Re: Automatic font change
Post by: rick2691 on December 04, 2016, 05:11:54 pm
Alextp,

Thanks for responding. I thought I had seen ATVsynedit in a "uses" clause. I must have been looking at too many things too fast. Thanks for correcting me.

When you do editing with your version of RichEdit, does it swap fonts and sizing by Font Binding?

Rick
Title: Re: Automatic font change
Post by: Alextp on December 04, 2016, 11:39:46 pm
Rick,
as I told, ATViewer uses usual RichEdit from Delphi (tested D7, x32, with Windows XP), so you may ask it at Delphi forums
Title: Re: Automatic font change
Post by: rick2691 on December 07, 2016, 01:48:41 pm
skalogryz,

I have found a temporary fix for auto font binding.

I found a non-unicode english font that has a nearly equal font metric to my Hebrew, Syriac, and Greek fonts. Each of the latter have close metrics to each other. They are Verdana, SBL Hebrew, SBL Greek, and Estrangela Edessa.

Since Verdana is not Unicode the Font Binding does not activate. But I had to retype my Manual document from scratch because it was too difficult to simply edit out all of the Binding attributes that were associated with the RTF file.

If a more internal fix can't be found, I will probably explore abandoning Unicode altogether. I will likely search for some non-unicode fonts for the other languages, or I will build my own fonts with the TypeTool program. As is, I have not found any adequate fonts for those languages.

For right now, I am happy to be evading the Binding nightmare... I have spent way too much time on its problem.

There is, however, another issue that I would like you to look into if you can. The following is a list of DLL's with their version and Class assignments. The information could be wrong, but they differ on Class assignments from what I have been trying to use by your advice. RichEdit.DLL is ClassName: 'RICHEDIT'. The RICHED20.DLL's are ClassName: 'RichEdit20A'. Only MSFTEDIT.DLL is ClassName: 'RichEdit50W'. All of the 20 DLL's have a suffix of A, but this wouldn't be the first time that I have found incomplete or misinformation about RichEdit.

When I try these Class names, RichEdit.DLL accepts the Class name but does not function at all. The 20 DLL's also accept the Class, but they won't do Unicode.

Using ClassName: 'RichEdit20W' on the 20 DLL's is accepted and will do Unicode. Therefore I am assuming that the list below has simply overlooked 20W Classes.

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.

Quote
RICHED32.DLL: v1.0
C:\Windows\System32\RICHED32.DLL
Wrapper Dll for Richedit 1.0
In XP:    File version: 5.1.2600.0
In W7:   File version: 6.1.7601.17514
In W10: File version: 10.0.10586.0
ClassName: 'RICHEDIT'

RICHED20.DLL:  v2.0
C:\Windows\System32\RICHED20.DLL
Rich Text Edit Control, v2.0
5.0.150.0
Microsoft RichEdit Control, version 2.0
ClassName: 'RichEdit20A'

RICHED20.DLL:  v3.0, in XP:
C:\Windows\System32\RICHED20.DLL
Rich Text Edit Control, v3.0
Product version: 3.0
File version:  5.30.23.1230
ClassName: 'RichEdit20A'

RICHED20.DLL:  v3.1, in W7, W10:
C:\Windows\System32\RICHED20.DLL
Rich Text Edit Control, v3.1
Product version: 3.1
File version:  5.31.23.1230
File version:  5.31.23.1231
ClassName: 'RichEdit20A'

Windows XP, Windows 7   :  v4.1
C:\Windows\System32\MSFTEDIT.DLL
Rich Text Edit Control, v4.1
Product version: 4.1
XP SP3:  File version:  5.41.15.1515
W7:       File version:  5.41.21.2510
ClassName: 'RichEdit50W'

Rick
Title: Re: Automatic font change
Post by: skalogryz 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.
Title: Re: Automatic font change
Post by: rick2691 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
Title: Re: Automatic font change
Post by: skalogryz 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.
Title: Re: Automatic font change
Post by: rick2691 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
Title: Re: Automatic font change
Post by: skalogryz 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.
Title: Re: Automatic font change
Post by: rick2691 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
Title: Re: Automatic font change
Post by: rick2691 on December 10, 2016, 06:29:26 pm
Even one image is too big. I'll have to resize the images.

Rick
Title: Re: Automatic font change
Post by: rick2691 on December 10, 2016, 09:10:37 pm
First group of images

Rick
Title: Re: Automatic font change
Post by: rick2691 on December 10, 2016, 09:11:25 pm
Second group of images

Rick
Title: Re: Automatic font change
Post by: rick2691 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
Title: Re: Automatic font change
Post by: skalogryz 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
Title: Re: Automatic font change
Post by: rick2691 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
Title: Re: Automatic font change
Post by: lainz 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
Title: Re: Automatic font change
Post by: rick2691 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
Title: Re: Automatic font change
Post by: rick2691 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