Recent

Author Topic: Automatic font change  (Read 40539 times)

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #45 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
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 #46 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
« Last Edit: November 20, 2016, 08:52:33 pm by rick2691 »
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 #47 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)


rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #48 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
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 #49 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
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

rvk

  • Hero Member
  • *****
  • Posts: 6111
Re: Automatic font change
« Reply #50 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.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: Automatic font change
« Reply #51 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)

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #52 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
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 #53 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
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 #54 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
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 #55 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
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

AlexTP

  • Hero Member
  • *****
  • Posts: 2386
    • UVviewsoft
Re: Automatic font change
« Reply #56 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



rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #57 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
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

AlexTP

  • Hero Member
  • *****
  • Posts: 2386
    • UVviewsoft
Re: Automatic font change
« Reply #58 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

rick2691

  • Sr. Member
  • ****
  • Posts: 444
Re: Automatic font change
« Reply #59 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
Windows 11, LAZ 2.0.10, FPC 3.2.0, SVN 63526, i386-win32-win32/win64, using windows unit

 

TinyPortal © 2005-2018