Hi. We are evaluating AcuToWeb. Our application is actually running in the 10.2.1 version and fairly well, so congratulations to the development team. We do a couple tricks which require W$TEXTSIZE to know the pixel length of strings as they appear on the screen. If we use W$TEXTSIZE, it works perfectly, but is very slow over an internet connection (repeated loops where server sends request to client and gets answer back, so high latency slows things down) We came up with a trick to operate over the internet (with thin client) where we cache the character sizes in our fonts, using W$TEXTSIZE once per character at startup instead of having to use W$TEXTSIZE on every string we display, since that is VERY slow. This works great on the thin client because the fonts don't use kerning or change size due to anti-aliasing, so the server can pre-calculate string sizes. When working with AcuToWeb, the strings are variable # of pixels per character, depending on what the text is. We tried turning off the anti-aliasing in the windows setup, and that worked - things started lining up again - but the workstation looked bad with everything else, so that's not a viable option.
We tried adding a css to turn off options that would change the font, and used this:
But no luck. Also, apparently the font-smothing thing is out of the current standard, and is expected to stop getting implemented, so is probably not a very good solution anyway.
Note: We were using browsers (tried several) on windows, so in theory using the same windows fonts that thin client is using.
Any thoughts? Did we get the .css right?
Well, we finally found the source of the problem - and it's not kerning (well it's 1% kerning - more later). The pixel size of any one character needs to have a fraction.
I think the issue is that the font has a "proper" size, which then has to be mapped onto the physical device, and if the string gets to a point where the next character SHOULD start an extra pixel further down the line, then it draws the current character slightly differently to make up the room.
Anyway, what I ended up doing was building an 80 character string filled with all the same character, then called WIN$TEXTSIZE, then divided the X pixels by 80. Keeping 2 decimals of the result. When I then do my own size routine, I can add up the fractions and round the total after it's done, and the result comes out the same as the WIN$TEXTSIZE routine.
The exception was if the string had back-to-back 1s digits. It turns out the 1s digit does kerning with itself, but not with the other digits. Go figure. I haven't done a deep dive yet on testing kerning for all pairs, but there definitely aren't many - that's why I haven't been in a rush.
So there you go - it turns out the issue wasn't kerning, it was a "pixel size" that is in fractions.
You wrote that you do a couple tricks which require W$TEXTSIZE to know the pixel length of strings as they appear on the screen.
Could you be more specific and send us a program sample of what you're doing ?
This could help us to try to reproduce the problem you're facing.
Thanks in advance
Did using AcuToWeb Desktop change the performance or the appearance?
- strings often get truncated slightly since I use pixel size for the display of labels and for unboxed entry fields. (We draw our own boxes - saves vertical space on the screen)
- some prompts have F1=action, F2=other action and we display a button over top of the text for F1/F2 etc, and
the buttons display in the wrong location when we use the caching trick.
1. Stephen asked if the issue was appearance or speed - it's appearance.
2. Roch asked for a sample program and I've got one now, but how do I upload the sample program? I'm not seeing an upload button, I assume I have to paste the source text into this reply box and let you do a copy/paste then compile it on your own? (Note: I just switched to rich text so I could bold this question, and I tried the drag/drop and the insert options. That apparently only works for images & videos.
3. Roch also asked what the tricks are. Centering, right justify and displaying an actual button over literals like "F1" or "F2" when a prompt string is displayed. Also, drawing our own box around an unboxed entry field - this allows us to use less space vertically so it's easier to fit 24 lines on a screen - especially with today's wide-screen monitors. But if you can't get the pixel size right, things get truncated. Or the button lets part of the F1/F2 text show. Looks fine in thin client because while the characters may be variable width when compared to each other, they always use the same # of pixels regardless of what character is next to them. The browser is being "smarter".
Well that worked. Excellent! Inside the file is the compiled object I used. And the source it was compiled from. The utility just opens a window, builds a table of character sizes for the font I picked, then loops: asks for a string, then shows the actual WIN$TEXTSIZE value and the computed-from-cache values. Run it in thin client and the 2 numbers are identical. In acutoweb, they are different - by a varying number of pixels depending on the string. To exit the loop, just leave the test string blank.
In AcuToWeb, the render is made by the browser and the calculation of the font size is generated by a calculation made by AcuToWeb itself (it its own js scripts).
We are looking into having WIN$TEXTSIZE be run by the AcuToWeb Desktop. We are hoping that will provide the accuracy your app needs.
I should note that the current WIN$TEXTSIZE computation is 100% accurate as far as I can tell, my application just has to call it too many times to be speedy on any connection with significant latency.