• State Not Answered
  • Date
  • Date 4 Jan 2019 0:59
  • Replies 9 replies
  • Subscribers 493 subscribers
  • Views 220 views
Product Documentation

In AcutoWeb - can I disable anti-aliasing so fonts work the same as thin client?

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:

.ui-control-label {
 font-kerning: none;
 font-smooth:  never;
 -webkit-font-smoothing: never;
 -moz-osx-font-smoothing: never;
}

 

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?

  • Hello Robert

    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

    Roch

  • Did using AcuToWeb Desktop change the performance or the appearance?

  • In reply to shjerpe:

    If I use W$TEXTSIZE, things look perfect but it's really sluggish over the internet. If I use the caching trick, speed is fine over the internet, but I have size errors which cause 2 problems:
    - 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.
  • In reply to RobertRedekop:

    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".

  • In reply to RobertRedekop:

    Use the rich text, select the Insert / Insert image / in the next dialog use the From drop down- change from Web to File upload and you should be able to attach a zip or source file.
  • In reply to RobertRedekop:

    fontcache.zip

    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 reply to RobertRedekop:

    Thanks, that reproduces nicely. I get this to our AcuToWeb team.
  • In reply to shjerpe:

    Thank you. Of note, this might be a kerning issue more than an anti-aliasing issue. And WIN$TEXTSIZE is working fine, it's just the behaviour of the web browser's rendering of the fonts.