IMPORTANT NOTICE:  As of 21 February, anything posted in this community WILL NOT BE MIGRATED to our new community site.   We have pulled all user information and data from this site and are now in an approximately week long process of importing users, roles, and data to our new site.  We are leaving this site open and active so you can post and hopefully get a response until the migration is complete.   Once complete, the URL  that currently takes you to this site will take you to our new site so your bookmarks will work as always.  Please read the information on a New Login Process

  • State Not Answered
  • Date
    RobertRedekop
  • Date 4 Jan 2019 0:59
  • Replies 13 replies
  • Subscribers 501 subscribers
  • Views 571 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?

  • Roch Rolland

    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

  • shjerpe

    Did using AcuToWeb Desktop change the performance or the appearance?

  • RobertRedekop

    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.
  • RobertRedekop

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

  • shjerpe

    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.
  • RobertRedekop

    In reply to shjerpe:

  • RobertRedekop

    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.

  • shjerpe

    In reply to RobertRedekop:

    Thanks, that reproduces nicely. I get this to our AcuToWeb team.
  • RobertRedekop

    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.
  • shjerpe

    In reply to RobertRedekop:

    Following up on this ... The WIN$TEXTSIZE function works fine in an AcuThin/wrun32.exe environment, because the rendering is made by Windows APIs on the display machine (which is always a Windows OS).

    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.
  • RobertRedekop

    In reply to shjerpe:

    When you say "AcuToWeb Desktop" are you referring to the server side of the browser/server connection?

    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.
  • DougP

    In reply to RobertRedekop:

    AcuToWeb Desktop is the browser-side executable that provides access to the client PC resources. The documentation for that is here:
    www.microfocus.com/.../GUID-FC25056C-3213-4C8B-9FD4-54DFED020E80.html
  • RobertRedekop

    In reply to DougP:

    Ahh. That would help with windows only, and is therefore not a good solution for us. Thank you, but only do that if you believe it would help someone else.

    I think I have a plan - expand the caching beyond single character, start caching character-pair size adjustments. ie) cache the basic character size for a and b, then cache the difference when b follows a (and when a follows b) so that the cache computation can add up the main size, then the difference when followed by the next character. I figure build the table in a thread so the user doesn't have to wait 5 minutes at startup. If I can identify returning workstations, then the caching only has to happen once.