Known Bugs

Organizing tasks to work on, New Features Ideas, Building LCS & LCB Libraries & Widgets, Redecorating and Modifying the IDE, Hacking / Editing Tools, Compiling the Engine from Source, etc.
Post Reply
User avatar
OpenXTalkPaul
Posts: 2173
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

OK I'm reading your nicely documented PDF Document now, there's a lot to unpack there.
1. Default text settings
When you create a new button or label in the IDE, its textFont is initialised to (Message). This placeholder is replaced by the LC engine with the font appropriate to the platform GUI. On Windows this is Segoe UI 12point. On the Mac, it is currently SF UI Text 13pt. For an input field the default is (Text), which resolves to Segoe UI 12pt or SF UI Text 12 pt respectively. Older Mac systems used to use Lucida Grande, and before that Helvetica. Linux systems will use whatever font is set for the particular distribution; for Ubuntu the font is Ubuntu 14pt.
Are you sure about that 'new button or label textFont is initialized to (Message)? I mean that (Message) is inheriting the appropriate button label font from the OS to match the OS version?
Or...vis this is actually set up in the startUp chain, defaults chosen by an IDE script based on 'the platform' value? This is (currently) 'hard-coded' / static in script, but I'd want to have them be user preferences. The Mac setting was not updated to San Fran. font, it was still set for Lucida Grande (macOS 10.9 Mavericks and lower System Font).
The handlers with those set in the script are in revCommonLibrary,livecodescript in the IDE around line 1290.
Here's how my modified version of that looks currently (with some notes in the comments:

Code: Select all

function revFontGetSystemFont
   switch _revFontGetPlatform()
      case "Windows"
         if word 1 of the systemVersion is "NT" and word 2 of the systemVersion >= 5 and "Segoe UI" is among the lines of the fontNames then
            return "Segoe UI"
         else if word 1 of the systemVersion is "NT" and word 2 of the systemVersion >= 5 and "Tahoma" is among the lines of the fontNames then
            return "Tahoma"
         else
            return "MS Sans Serif"
         end if
         break

      case "MacOS X"
         if "SF Pro Regular" is among the lines of the fontNames then
            return "San Francisco Pro Text"
         else
            return "Lucida Grande"
         end if

         break

      case "Linux"
         return "Helvetica"
         break

      case "iphone"
         return "San Francisco"
         break

      case "android"
         return "Roboto"
         break

   end switch
   -- Default sans-serif font in MacOS
   -- MacOS (El Capitan and newer) San Francisco
   -- MacOS (Yosemite) Helvetica Neue
   -- MacOS (older versions) Lucida Grande
   -- Please note that — although for interface San Francisco is the default
   -- sans-serif font — for web -apple-system will need to be used, as the
   -- sans-serif fallback will display Helvetica instead of San Francisco.
   --(this is one of the quirks I mentioned earlier)

   -- Default sans-serif font in Windows
   -- The difference between Microsoft Sans Serif and MS Sans Serif is that MS Sans Serif was a
   -- bitmap/raster font available in 8, 10, 12, 14, 18, and 24 sizes and Microsoft Sans Serif is a TrueType scalable font.

   -- MS Sans Serif was based on Helvetica and in all versions up to Windows 3.1 it was called Helv.
   --Windows (Vista and newer, including Windows 10) Segoe UI
   -- Windows (XP) Tahoma
   -- Windows (2000) Microsoft Sans Serif
   -- Windows (95, NT, Millennium) MS Sans Serif
   -- Windows (older versions including Windows 3) Helv
   -- Default sans-serif font in Linux: Many Linux users re-configure defaults to other fonts like Inter UI or others.
   -- So it’s almost impossible to accurately mention defaults, except for the Ubuntu distro
   --  which has its own font as default.
   -- Red Hat also has commissioned its own fonts Red Hat Display and Red Hat Text.

   -- Ubuntu - Ubuntu
   -- Red Hat = Red Hat
   -- Other distros (Arch Linux, Debian, Fedora etc.) varies, can be DejaVu Sans, Noto Sans, Liberation Sans etc.

   -- iOS (9 and newer)and iPadOS San Francisco
   -- iOS (8 and older) Helvetica/Helvetica Neue

   -- watchOS = San Francisco Compact
   -- Android (4.0+) Roboto
   -- Android (older versions) Droid Sans
end revFontGetSystemFont

function revFontGetSystemFontSize
   switch _revFontGetPlatform()
      case "Windows"
         if word 1 of the systemVersion is "NT" and word 2 of the systemVersion >= 5 and "Segoe UI" is among the lines of the fontNames then
            return 12
         else if word 1 of the systemVersion is "NT" and word 2 of the systemVersion >= 5 and "Tahoma" is among the lines of the fontNames then
            return  11
         else
            return 10
         end if
         break

      case "MacOS X"
         return 11
         break

      case "Linux"
         return 12
         break

      case "iphone"
         return 17
         break

      case "android"
         return 14
         break

   end switch
end revFontGetSystemFontSize

function  revFontGetSystemFontStyles
   return empty
end revFontGetSystemFontStyles
That drops back to Lucida Grande if SF Pro Regular is not found on macOS. I'm not sure that you can or you're supposed to use Apple's special UI fonts (which nominally would not appear in fontNames nor in most apps font menus, and may be invisible fonts/files in the systems fonts. Also, you can see the handler revFontGetSystemFontSize provides font sizes, those could maybe be adjusted too.

This all ties in with another recent discussion of the subject of 'classic controls' not really being native UI toolkit objects, they're more like emulations of 'native' with some (but not all) color properties inherited from the OS and appropriate font guessed at in that script above?

This makes me think (again) about how maybe we should just have a replacement set of 'classic controls'-as-widgets. The canvas drawing should render the same on any of the platforms (provided all using the exact same font). Maybe just have a generic set of controls, such as buttons with middle of the road defaults, but which are also customizable enough that one could match any OS reasonably well if they want to, and skipping that whole 'Native Button' thing.
User avatar
neville
Posts: 35
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: Known Bugs

Post by neville »

Paul: The resolution of the various platform would only make a minuscule difference in the positioning of the test. I am talking up to 10 pixels in vertical displacement. The document which illustrates this is posted here... Windows always renders the text a few pixels below where it would be on a Mac. Even if you don't read the full doc have a look at the rather telling screen shots in Example 3: a carefully crafted layout designed on a Mac becomes a dog's breakfast when rendered on Windows.

As for horizontal (text length) differences between the platforms, Mac and Windows *mostly* now get the same length for rendered text to within a fraction of a pixel, probably within antialiasing, since Windows 10 [before that not so] – IF you use your own installed fonts or a small range of fonts which are common to both OS's (leaving the stack to do its own thing, while usually best practice to give the user their accustomed look-and-feel, is sure to get very different lengths if only because the default font sizes for the 3 platforms are different).

I tested over 700 fonts with various styles, over 4600 font files in total. Because of problems with accessing font styles on Windows and other things, there were 1856 combinations of font/pointsize/style which could be installed on both platforms. There were about 200 cases where the lengths differed between Mac and Windows (Why? Font rendering is the work of the devil and you go there at your own peril). A very small number of those were actually commonly used fonts, most were niche fonts; the "safe" fonts included Arial, Times New Roman, Courier New, Impact, Tahoma, Noto Sans, Noto Serif.

Linux (Ubuntu) however gets quite different lengths, perplexingly sometimes shorter sometimes longer for the same font at different font sizes. All of this means if you are designing on one platform you need to allow some extra room for labels (about 10% is adequate as I recall for all 700 fonts I tested at a range of point sizes from 8 to 24 , 5% is usually enough). And you simply cannot rely on vertical alignment at both ends of text strings across Linux and Mac/Windows (mobile?? who knows??)

I wonder if that is why LC does not implement full text alignment of fields, maybe cross-platform full text alignment requires a custom font engine rather than relying on the platform OS, and I really don't think LC or we should go there, that is a real can of worms - tho you do seem to be exploring that dark and dangerous space?

How these problems affect vertically written text languages is another interesting topic that I have not gone in to (no expertise at all there).

On music scores ... no, just a very peripheral side interest.

The algorithm for getting the position of the baseline of the first line of text in a field, which is accurate for Windows and Linux and almost always on Mac, is included in the posted pdf doc. Unfortunately to use it in practice you would have to include a run-time test for each platform each time you wanted to get accurate vertical alignment. Which is why I made the feature request (ignored) for getBaseline, setBaseline handlers.

Neville
User avatar
neville
Posts: 35
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: Known Bugs

Post by neville »

Paul: Did my pdf file on Cross-platform font problems actually get posted ... you appear to reading it but it doesn't show in my post (which was submitted after your reply ;-?)
User avatar
neville
Posts: 35
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: Known Bugs

Post by neville »

On (Message) etc, it was true for my LC settings at the time anyway that they were placeholders which by default were replaced by System fonts (which did indeed vary between versions of OS's as well as platforms) That would be correct to ensure look-and-feel. I thought they could also be overridden by the user in LC preferences however, I am hazy on the details now.
User avatar
neville
Posts: 35
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: Known Bugs

Post by neville »

Looking at your code I'm sure you have a more accurate idea of what is going on; the document was concerned with demonstrating that different OS = different default fonts = different layout and while I tried to be very careful I may well have got the fine details wrong (I usually do). The possible discrepancies between San Fran fonts ... I think that various versions labelled "UI text" or "Pro" etc could be identical fonts in practice. On using Apple System fonts, I believe the situation is you can use them as long as they are only displayed on an Apple machine, so you shouldn't embed an Apple System font within an OtX stack and then display it on a Windows box. I guess it is not OK to embed an Apple System font in a pdf document in that case.
User avatar
neville
Posts: 35
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: Known Bugs

Post by neville »

getting obsessive here ... apologies to other readers ... my pdf doc was written in 2023, so would have referred to a version of LC after LCE, so probably LC had updated the Mac system font settings to San Fran by then, so that would explain our differing experiences of (Messages). And I still don't see the pdf doc posted so other readers can access it.. I presume it needs moderation?
mwieder
Posts: 130
Joined: Sun Jun 04, 2023 3:32 am
Location: Berkeley, CA, US, Earth
Contact:

Re: Known Bugs

Post by mwieder »

neville-

I don't see your pdf here but it's in your dropbox and linked to in the bug report.
I can see it from there.

Fonts is a sticky subject. It shouldn't be a problem (famous last words) to add the properties to field objects, but beyond that the manipulation of field and font properties to deal with baselines and string lengths sounds like a briarpatch.
User avatar
neville
Posts: 35
Joined: Wed Jul 31, 2024 1:03 am
Location: Canberra, Australia
Contact:

Re: Known Bugs

Post by neville »

Cross-platform text appearance.pdf
(498.2 KiB) Downloaded 18 times
Ah, thanks. Paul was probably reading the pdf from my dropbox, and I just neglected to upload it. Let's try that again...
mwieder
Posts: 130
Joined: Sun Jun 04, 2023 3:32 am
Location: Berkeley, CA, US, Earth
Contact:

Re: Known Bugs

Post by mwieder »

Yep. That did it.
Skids
Posts: 68
Joined: Thu Dec 22, 2022 9:40 am
Location: North Lincolnshire
Contact:

Bug - inspector fails to show gradient ramp

Post by Skids »

I have just noticed that the fill gradient ramp is not being shown in the control inspector. I was expecting this:
Screenshot 2024-08-16 at 17.37.46.png
Screenshot 2024-08-16 at 17.37.46.png (80.04 KiB) Viewed 1983 times
instead this was displayed :
Screenshot 2024-08-16 at 17.33.10.png
Screenshot 2024-08-16 at 17.33.10.png (20.33 KiB) Viewed 1983 times
I'm pretty sure that the ramp was available in 9.6.3

Thoughts?
Skids
Posts: 68
Joined: Thu Dec 22, 2022 9:40 am
Location: North Lincolnshire
Contact:

Re: Bug - inspector fails to show gradient ramp

Post by Skids »

I have just confirmed that it is present in OXTLite 1.07.
User avatar
tperry2x
Posts: 2378
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Bug - inspector fails to show gradient ramp

Post by tperry2x »

Hi Skids,
Yes - I know about this one (unfortunately).
You can get it to work, but you might have to close the window a few times occasionally and retry.
The inspector also occasionally freaks out with drop shadows. (These are the other reasons why I'm making my own inspector).
working.png
working.png (86.86 KiB) Viewed 1980 times
(just moving this to the known bugs section).
User avatar
tperry2x
Posts: 2378
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

In fact, messing about with the FX in the standard palette induces a whole series of bugs, which ramp up the CPU use.
(another reason for my new "Properties" stack).... just that always gets pushed to the background when I've got other bits to fix:
effects.png
effects.png (116.42 KiB) Viewed 1974 times
User avatar
OpenXTalkPaul
Posts: 2173
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Bug - inspector fails to show gradient ramp

Post by OpenXTalkPaul »

Skids wrote: Fri Aug 16, 2024 4:45 pm I have just noticed that the fill gradient ramp is not being shown in the control inspector. I was expecting this:
Screenshot 2024-08-16 at 17.37.46.png

instead this was displayed :
Screenshot 2024-08-16 at 17.33.10.png

I'm pretty sure that the ramp was available in 9.6.3

Thoughts?
Yeah this one annoys me frequently, I think I'll look into this one, as it pertains to the pre-existing Property Inspector (hopefully this bug would not make it's way into Tom's new Props Inspector).

If you just hit OK/enterKey when you get that mangled PI window UI, and then re-open whichever graphic effect thing it was you were trying to edit, then the second time it arranges the UI for that effect the way that it should look, so my guess is there's something in those that is not being initialized properly on the first try, but is present once you set something and then re-open the problem window.

I would LOVE to be able to add gradient presets sets to the IDE somewhere, that way we can have pre-made color ramps sets Like 'Brimstone"', "Black graduating to transparent vertical", "Metallic", "Easter egg pastels", etc.
User avatar
OpenXTalkPaul
Posts: 2173
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

Note: That gradient ramp editor is a Widget that comes with the IDE.
I'm not sure how that worked before Widgets were introduced in v8, it was probably in a sub-stack.

Looking at the screenshots of "Fill Gradient" window and the mangled window "fillGradient", noticed the title bars are have different names, I wonder if that's part of the problem?
User avatar
OpenXTalkPaul
Posts: 2173
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

Tom, you've mentioned a permissions issue in Windows 11 where revCopy triggers scary warning in Win Explorer,
I wonder if the LCB equivelant is using the same method for file I/O, if it's different it may not have the same problems if you used LCB to copy/move/read/write to files? It's looks like it is bound to the Engine internal methods so probably will trigger the same issue, but it might be worth testing it out.

This is the xB language Module that creates xB's file I/O syntax:
https://github.com/livecode/livecode/bl ... c/file.lcb

To read an entire file in xBuilder you:

Code: Select all

put the contents of tMyFilePath into tMyFileData
Doh, I just found some more non-documented xBuilder Syntax, wow!

Code: Select all

 put the entries of directory tMyDirectoryPath into tMyDirectoryListing
Skids
Posts: 68
Joined: Thu Dec 22, 2022 9:40 am
Location: North Lincolnshire
Contact:

Re: Known Bugs

Post by Skids »

Another feature of the empty fillgradient palette is that it stays open when the parent is closed.
User avatar
tperry2x
Posts: 2378
Joined: Tue Dec 21, 2021 9:10 pm
Location: Somewhere in deepest darkest Norfolk, England
Contact:

Re: Known Bugs

Post by tperry2x »

OpenXTalkPaul wrote: Sat Aug 17, 2024 1:33 am Tom, you've mentioned a permissions issue in Windows 11 where revCopy triggers scary warning in Win Explorer,
I wonder if the LCB equivelant is using the same method for file I/O, if it's different it may not have the same problems if you used LCB to copy/move/read/write to files? It's looks like it is bound to the Engine internal methods so probably will trigger the same issue, but it might be worth testing it out.
Unfortunately I don't have access to a Windows 11 test machine at the moment, but will try and test when I next encounter one.
Skids wrote: Sat Aug 17, 2024 6:54 am Another feature of the empty fillgradient palette is that it stays open when the parent is closed.
Is this what you mean, or is this another bug?
I think this might be another bug. If you are editing the 'gradient ramp' of a gradient, using the inspector - and you set an angle - you can't dismiss the handles. The only way is by closing and reopening the stack. (even navigating to a different card won't help).
(you can see they are stuck on here, while the browse tool is chosen). It gets stuck when you manually drag the rotation point.
gradbug.png
gradbug.png (10.73 KiB) Viewed 1696 times
Why does it increasingly feel like it's better to "assume it's broken, rather than assume that it works" until proven otherwise?
User avatar
OpenXTalkPaul
Posts: 2173
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

tperry2x wrote: Mon Aug 19, 2024 6:25 pm Is this what you mean, or is this another bug?
I think this might be another bug. If you are editing the 'gradient ramp' of a gradient, using the inspector - and you set an angle - you can't dismiss the handles. The only way is by closing and reopening the stack. (even navigating to a different card won't help).
(you can see they are stuck on here, while the browse tool is chosen). It gets stuck when you manually drag the rotation point.
Yes, this has long been an issue, editing the points of graphic object had similar issue, but I fixed that.
However, unlike edit the point of a graphics, the gradient ramp handles do not have a corresponding menu item in the revMenuBar nor in the Edit Context Menu. I think it should be there, directly under the 'Edit Points' and should be enabled if user is in the 'A Single Graphic is Selected' context (see revMenuBar scripts) and the Graphic object has a Gradient Ramp applied to it. It must already be in a (frontscript/backscript) script that's already separate from the Property Inspector.
User avatar
OpenXTalkPaul
Posts: 2173
Joined: Sat Sep 11, 2021 4:19 pm
Contact:

Re: Known Bugs

Post by OpenXTalkPaul »

I mentioned somewhere that there was undocumented syntax in xBuilder for Encoding/Decoding various formats like Base64, but I tried using it and it doesn't work, the module is not in the 'built-ins', and I couldn't get the encode.lcb source to compile.
Now I just found out why, it was basically unfinished work since back around 2015 or so.
https://forums.livecode.com/viewtopic.php?t=29921

I still may try to get that working, at least partially working for encode/decode tMyData as base64 (as Ali Mentioned in his comment).
Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests