How is a *font* involved in UTF-8 encoding?
IMO IsUnicodeFont would be a better name.
DoDi
Mailing lists / lazarus / 2011-11
FontCanUTF8(Font: HFont)
5 messages · 3 people · –
- Felipe Monteiro de Carvalho 2
- Hans-Peter Diettrich 2
- Mattias Gaertner 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
You have to read the implementations to see what the routines do, and in this case it looks pretty clear that it is a legacy introduced because LCL-gtk1 needed it.
It probably can be deprecated.
function TGTKWidgetSet.FontCanUTF8(Font: HFont): boolean;
begin
Result:=IsValidGDIObject(Font)
{$IFDEF Gtk1}
and FontIsDoubleByteCharsFont(PGdiObject(Font)^.GDIFontObject)
{$ENDIF}
;
end;
function TWin32WidgetSet.FontCanUTF8(Font: HFont): boolean;
begin
{$ifdef WindowsUnicodeSupport}
Result := True;
{$else}
Result := False;
{$endif}
end;Felipe Monteiro de Carvalho
Show quoted text 5 lines
You have to read the implementations to see what the routines do, and
in this case it looks pretty clear that it is a legacy introduced
because LCL-gtk1 needed it.
It probably can be deprecated.
Reading the implementation doesn't help much, as can be seen with your example:
Show quoted text 8 lines
function TGTKWidgetSet.FontCanUTF8(Font: HFont): boolean;
begin
Result:=IsValidGDIObject(Font)
{$IFDEF Gtk1}
and FontIsDoubleByteCharsFont(PGdiObject(Font)^.GDIFontObject)
{$ENDIF}
;
end;
What does *FontIsDoubleByteCharsFont* mean? This *might* mean UTF-16, but then the name *FontCanUTF8* already is wrong.
IMO a usable software should *not* require the user to guess, what various implementations *might* do. Instead the *implementors*, who *know* what to implement, should leave at least a small note on the purpose of every procedure or method. That's little work for the Lazarus team, which saves many months to the documentation writers :-]
Not to forget possibly or definitely wrong descriptions, as found in many places in the documentation :-(
DoDi
Hans-Peter Diettrich wrote 5 lines
Reading the implementation doesn't help much, as can be seen with your
example:
What does *FontIsDoubleByteCharsFont* mean? This *might* mean UTF-16, but
then the name *FontCanUTF8* already is wrong.
It doesn't matter what it does, the important thing is seeing that it does something in LCL-Gtk1 and does nothing useful in all other widgetsets. Gtk1 is obsolete, so the routine currently does nothing useful.
IMO a usable software should *not* require the user to guess From what I see, users should not use this routine. As mentioned in my
previous e-mail it looks a legacy from the past when Lazarus still used ansi-encoded strings in some widgetsets.
It does not look useful nowadays, so I propose deprecating it. Anyone opposed?
Felipe Monteiro de Carvalho
Show quoted text 7 lines
On Sat, Nov 26, 2011 at 10:27 AM, Hans-Peter Diettrich
wrote:
> Reading the implementation doesn't help much, as can be seen with your
> example:
>
> What does *FontIsDoubleByteCharsFont* mean? This *might* mean UTF-16, but
> then the name *FontCanUTF8* already is wrong.
AFAIR it means UCS2. The name DoubleByte is somewhat misleading.
Show quoted text 10 lines
It doesn't matter what it does, the important thing is seeing that it
does something in LCL-Gtk1 and does nothing useful in all other
widgetsets. Gtk1 is obsolete, so the routine currently does nothing
useful.
> IMO a usable software should *not* require the user to guess
>From what I see, users should not use this routine. As mentioned in my
previous e-mail it looks a legacy from the past when Lazarus still
used ansi-encoded strings in some widgetsets.
It's legacy. It has nothing to do with ansi-encoded. gtk1 had some fonts that only supported 8bit.
It does not look useful nowadays, so I propose deprecating it. Anyone opposed?
No objection here.
Mattias