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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?