formattedwidth Failing / Bug on Server

[istech]

Hi Livecoders,

I do hope you are doing well in your projects and staying productive.

I have been using the latest Livecode Server 9.6.8 and when I want to get the formattedwidth of a field it always returns 0 (Even when text is in the field). Can anyone confirm this is a bug? and maybe offer a workaround for the problem? Can be quite frustrating seeing the same code work on the Windows IDE to not work on the server edition.

Many thanks for your time.

[FourthWorld]

Does your server have a GUI? Which OS version is it running?

[istech]

Hi Richard,

Thanks for the reply.

I'm using CENTOS with no GUI. Just very strange. Maybe I am missing something as the docs say the command supports server and Linux. So should work? I have tried the width of the same field and works as expected, but the formattedwidth always return 0 not matter what text is in there.

[FourthWorld]

Is Pango installed on that server?
Have you run ldd with LC to see what dependencies may be missing?

[istech]

Hi there,

Just checked and yes Pango is installed. Plus the ldd read out is below. Let me know your thoughts. The server is quite old maybe my pango version is outdated? Never knew this was a dependant.

Kindest Regards,

Tony

pango.x86_64 1.28.1-11.el6 @base

LDD: read out on livecode server
linux-vdso.so.1 => (0x00007fffca37e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb8ee0a6000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb8ede86000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fb8edc56000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fb8ed9b6000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007fb8ed77e000)
librt.so.1 => /lib64/librt.so.1 (0x00007fb8ed56e000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fb8ed266000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb8ecf5e000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb8ecd46000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb8ec97e000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb8ee2ae000)

[paul@researchware.com]

This bug was supposedly fixed in 9.6.1rc1 and appears fixed on desktops (macOS and Windows), but perhaps it's not fixed for server? See https://quality.livecode.com/show_bug.cgi?id=22882

Affected formattedRect and formattedWidth but not formattedHeight

[FourthWorld]

Tony, If updating the server engine to v9.6.9rc1 fixes the issue, it may be related to what Paul experienced.

But since you're not experiencing a crash my hunch is yours is a different issue.

AFAIK the formattedWidth is not something LC can calculate on its own, dependent on the font rendering subsystem in the OS to render the text and obtain the metrics related to that rendering.

Have you been able to confirm text is rendering in the field at all on the server? Maybe try exporting a snapshot of the card.

If no text is rendered that would explain why the formattedWidth is zero. Then we can focus on what's needed to get a faceless system outfitted for GUI rendering.

And definitely update the OS if it's old. That'll rule out possible causes with libs that may have been fixed, and provide you with a cleaner, safer server overall.

[LCMark]

Where is the field which is being measured?

Fields on stacks (cards in fact) which are not open (which is different from being loaded - and being able to execute script!) will return 0 for any measurement operations as the field only sets up the internal layout structures when the control is opened.

So try using 'go invisible <stack>' before attempting to get the field's text measurements (indeed, also ensure the stack is on the right card too!).

[istech]

@ Richard, I can confirm the text is rendering fine. To add, the snapshot turns out fine. But the formattedwidth is not acquired and is always 0. Server now updated.

@ Paul I am leaning towards your thinking but need to check every possible option first. My server is the wild card here.

@ Mark the field is at the bottom of the card, I only have 1 card in the stack and the text renders fine as said before. So I need to open the field first? before trying to use the formattedwidth? So, load stack - go invisible - open field - input text - then use the formattedwidth function?

Can you confirm this is the case? also why only for formattedwidth function? as the "width" works without this procedure.

Many thanks

[istech]

Where is the field which is being measured?

Fields on stacks (cards in fact) which are not open (which is different from being loaded - and being able to execute script!) will return 0 for any measurement operations as the field only sets up the internal layout structures when the control is opened.

So try using 'go invisible <stack>' before attempting to get the field's text measurements (indeed, also ensure the stack is on the right card too!).

SOLVED:

Using the "go invisible <stack>" seems to get the formattedwidth working. Still strange that "the width" of a field still works without the "invisible" property. Thanks for teaching me something new about LC Mark much appreciated for everyone's help. Definitely a head-scratcher for me.

[FourthWorld]

Still strange that "the width" of a field still works without the "invisible" property.

Width is an object property, fully under LC's control. But formattedWidth is dependent on the OS font renderer, so it requires invocation through rendering to become discernible to LC.

I believe the key to Mark's suggestion wasn't the "invisible" part, but the going. When LC goes to a card it unpacks all the parts in a way that invokes the font system, then allowing rendered font metrics to become available.

If I understand where he's coming from, the "invisible" part just allows the "go" to trigger the unpacking and invoking, but in a way that doesn't trigger any attempt to use the window manager to render the final composite, needed here because most servers don't have GUI support, no window manager.

[istech]

As always Richard thanks for your input and dedication to the community. It is much appreciated.

[LCMark]

I believe the key to Mark's suggestion wasn't the "invisible" part, but the going. When LC goes to a card it unpacks all the parts in a way that invokes the font system, then allowing rendered font metrics to become available.

If I understand where he's coming from, the "invisible" part just allows the "go" to trigger the unpacking and invoking, but in a way that doesn't trigger any attempt to use the window manager to render the final composite, needed here because most servers don't have GUI support, no window manager.

Heh - yes - sorry - the *go* is the important part...

The *invisible* isn't necessary on server though as there's no difference between visible and invisible windows (as no 'system' window objects are created - same as if you run the standalone engine in -ui mode). It's just good practice - should the code you are running on server ever be used in a desktop / mobile build to do invisible field manipulations

[istech]

I believe the key to Mark's suggestion wasn't the "invisible" part, but the going. When LC goes to a card it unpacks all the parts in a way that invokes the font system, then allowing rendered font metrics to become available.

If I understand where he's coming from, the "invisible" part just allows the "go" to trigger the unpacking and invoking, but in a way that doesn't trigger any attempt to use the window manager to render the final composite, needed here because most servers don't have GUI support, no window manager.

Heh - yes - sorry - the *go* is the important part...

The *invisible* isn't necessary on server though as there's no difference between visible and invisible windows (as no 'system' window objects are created - same as if you run the standalone engine in -ui mode). It's just good practice - should the code you are running on server ever be used in a desktop / mobile build to do invisible field manipulations

Thank you for the extra clarification Mark and for your time. Cheers