Hi all,

when I checked what HTML2TextRenderer uses to translate list items, I found that since rev 55743 it uses U+26AB MEDIUM BLACK CIRCLE ⚫ and U+26AA MEDIUM WHITE CIRCLE ⚪. There seems to be some issue with these codepoints when rendering them to a Canvas on win32 widgetset: they only render correctly in an application when they are not the first character in a sequence OR the host is Win10, but never in the Lazarus SynEdit.

The slightly smaller versions U+25CF BLACK CIRCLE ● and U+25CB WHITE CIRCLE ○ work fine.

Example (make sure to save in UTF8, default in Lazarus):
-------------------
procedure TForm1.FormPaint(Sender: TObject);
var
  s: string;
begin
  s:= '●⚫';
  Canvas.TextOut(100,100,s);
  s:= '⚫';
  Canvas.TextOut(100,150,s);
end;
-------------------
The first TextOut produces 2 circles (the first one being smaller), the second a
"missing glyph" box. The second line will also do that in the code editor. It
may work in the application on Win10, but not on older systems.

Could someone please test this on other widgetsets, so I have an idea whether/what/where to report this?
Thanks!

Hi,
 
it seems OK on Qt and

...

Could someone please test this on other widgetsets, so I have an idea whether/what/where to report this?
Thanks!

Martok wrote

when I checked what HTML2TextRenderer uses to translate list items, I found that since rev 55743 it uses U+26AB MEDIUM BLACK CIRCLE ⚫ and U+26AA MEDIUM WHITE CIRCLE ⚪.

No. Since r55743 it uses one of the star emojis.
See in constructor THTML2TextRenderer.Create:
  fListItemMark:='✶ ';
  //fListItemMark:='✳ ';
  //fListItemMark:='✺ ';
  //fListItemMark:='⚫ ';
  //fListItemMark:='⚪ ';

I left the other potential choises in comments there for easy comparison.

Could someone please test this on other widgetsets,

It is not related to widgetsets anyhow. It only depends on the font your system uses.
I also had problems seeing Unicode emojis on Windows but never on Linux distros. To my surprise some fellow Lazarus developers complained they don't render properly in their Linux systems. That is why I changed the title emoji from a small diamond (outside BMP) to a big diamond (belongs to BMP). For some reason their fonts support it better.

  //fTitleMark:='🔹';     <-- this did not show in some people's system.
  //fTitleMark:='◆';
  //fTitleMark:='◇';
  fTitleMark:='◈';
  //fTitleMark:='◊';

The stars and circles mentioned earlier belong to BMP.

so I have an idea whether/what/where to report this?

Report to your OS manufacturer / project.
In case of Windows: Microsoft. Let's see how quickly they fix it. In any case those widely used Unicode emojis really must be supported. There is no excuse.

Juha

On Monday, October 16, 2017, Juha Manninen via Lazarus <

wrote: On Mon, Oct 16, 2017 at 4:43 PM, Martok via Lazarus wrote: > when I checked what HTML2TextRenderer uses to translate list items, I

found that

> since rev 55743 it uses U+26AB MEDIUM BLACK CIRCLE ⚫ and U+26AA MEDIUM

WHITE

distros.

Is it not possible to bundle supported resources in the LCL? That seems like the typical solution for Windows. On other OSes this is less proper, but I have still seen it done.

R0b0t1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171016/1734b986/attachment.html>

On Mon, Oct 16, 2017 at 8:56 PM, R0b0t1 via Lazarus <

Excuse me?
How could LCL bundle the fonts used by your OS?

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171016/e0623b7a/attachment.html>

It is not necessary to rely on only the system font collection, even when using WinAPI forms:
https://msdn.microsoft.com/en-us/library/system.drawing.text.privatefontcollection.aspx. Something similar is done in C++.

Admittedly there does seem to be some confusion about whether you can make certain UI objects (non-GDI+, specifically) take on face of these fonts, but I suspect you can, as it seems that there is a common underlying graphics system that the old APIs use. Even if not it would be possible to distribute an open font with Lazarus/the LCL and install it when Lazarus/the LCL is installed.

R0b0t1.

Am 17.10.2017 07:19 schrieb "R0b0t1 via Lazarus" <

proper,

https://msdn.microsoft.com/en-us/library/system.drawing.text.privatefontcollection.aspx .

If anything that should be part of the application's setup, not of the application itself nor of the LCL.

Regards
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20171017/9dfec858/attachment.html>

Thank you for clarifying - I wasn't sure if the OP was also talking about an issue with the code editor. However, I think inclusion of fonts in the LCL might make sense if it is found that system fonts are lacking for popular platforms.

The LCL is (to my knowledge) linked in to applications generated with Lazarus and never installed separately. Some toolkits for other languages, installed separately, ship with (optional) resource files. Compiling in the resources to every program which uses the LCL is a bit different, but the same principle.

R0b0t1.

R0b0t1 wrote

Thank you for clarifying - I wasn't sure if the OP was also talking about an issue with the code editor.

Neither was I - now I know it's not something that can be fixed on LCL/FPC side, so that's that. Guess there's a reason why browser vendors use third party text renderers...

It was theoretically possible that this codepoint triggers some sort of corner case in UTF8 processing (why would it matter if a character is the first or second in a string?), but it appears everything is fine and windows just does windows things.

Thank you for clearing that up!