LB Booster
General >> General Board >> Typographical issues http://lbb.conforums.com/index.cgi?board=general&action=display&num=1470992873 Typographical issues
Post by Richard Russell on Aug 12th, 2016, 09:07am
I am perhaps a little unusual in having a background in both programming and typography (my father was a commercial artist and I have done some manual typesetting in my time). It is therefore somewhat frustrating to see the degree of misunderstanding that some programmers seem to have about issues such as Dots Per Inch values, points versus pixels, dialog box scaling and the like.
There is a thread over at the LB Community Forum at the moment (to which of course I cannot contribute) in which some people are making various - and more often than not misleading - statements about how LB behaves with different font sizes and why the automatic dialog scaling doesn't always seem to work.
If anybody has any questions about typographical issues, particularly in how they relate to LB or LBB programming, feel free to post them here and I will try my best to answer in layman's terms.
Richard.
Re: Typographical issues
Post by joker on Aug 12th, 2016, 09:41am
Richard, for a start, could you go through those "misleading statements" from the LB forum posts one by one and clear them up in a logical manner?
Re: Typographical issues
Post by Richard Russell on Aug 12th, 2016, 11:54am
Richard, for a start, could you go through those "misleading statements" from the LB forum posts one by one and clear them up in a logical manner?
I'm loathe to make negative comments when the people concerned may not be aware of them and therefore aren't in a position to reply. But to pick up on a couple of things: Because dialog boxes scale their contents automatically according to the font size and DPI setting, there seems to be a belief that this should always work faultlessly. In other words if you design a dialog box and it looks correct with a specific font size, it should look correct with any other typeface or size without extra effort.
This is an entirely unreasonable expectation. Consider the case of a STATICTEXT control: you specify both the text to be displayed and the width of the control. If, by accident or design, you happen to specify a width which is only just enough to accommodate the text (maybe not even one pixel spare), when LB/LBB attempts to scale the control for a different DPI or font it is entirely possible that now the text doesn't quite fit. This is not a bug, it's a consequence of the scaling operations (of the static control on the one hand and the text on the other) only being able to work to the nearest pixel.
When this happens, rather than blaming LB for being "broken", you need to increase the width of the STATICTEXT control so that there is a more generous margin (perhaps make the box a few pixels wider than the text) so there is then a greater chance that it will still fit after scaling.
Somebody made the following comment: "if Windows doesn't find the correct size of the font and therefore uses an approximation, mostly it is the next bigger font". That's not correct, and it's also an area where LB and LBB differ slightly. The conversion from 'points' to 'pixels' is achieved by multiplying by DPI/72 (one point is 1/72"), so at the standard 96 DPI this means multiplying by 1.333...
Empirically it would seem that LB 4 does this by calling the Windows muldiv API; this rounds the result to the nearest integer value. By contrast LBB does it using the calculation int(points * DPI / 72) which rounds down to the smaller integer. So when specifying a font size in points, LB and LBB may not always produce identical results; LBB may use a font which is one pixel smaller. Neither of them rounds up to the next larger font.
Somebody else commented: "I don't know why you would waste a perfectly good hires screen by running it at 150%". Taken at face value this seems to indicate a fundamental misunderstanding of what DPI is all about.
The idea is that the size at which text is displayed should be approximately the same irrespective of the display's resolution. So a 14" display with a 1024x768 resolution (approx. 96 DPI) should display text at about the same size as a 14" display with 1600x1200 resolution (approx. 144 DPI). After all the optimum size is determined by the physical dimensions of the display, the distance from which it is viewed, and the visual acuity of the user.
A higher resolution display (with the same physical dimensions) can show more detail, and it can render graphics and text with a higher quality, but you do not generally want it to display things smaller! Of course the kind graphics that LB and LBB support natively, i.e. Windows GDI graphics, are not antialiased and (for example) a line can only be drawn with an integer width in pixels, so they cannot be scaled arbitrarily. But this is not a fundamental limitation; you could use antialiased GDI+ graphics, which allow you to specify coordinates and line widths etc. as floating-point values.Richard.
Re: Typographical issues
Post by CryptoMan on Aug 12th, 2016, 8:32pm
Isn't it impossible to set the precise width of a textbox when you use a proportional font no matter how precisely and correctly you make your arithmetics.
For example Mr.IIIIIIIIIIIIIIIIIIII and Mr.OOOOOOOOOOOOOOOOOOOO both have 20 characters in their names.
IIIIIIIIIIIIIIIIIIII OOOOOOOOOOOOOOOOOOOO
If you are using a proportional font like Arial all glyphs may have different width. Therefore, according to which you will set your Name field in your form?
But if we use a non-proportional font like Courier than a correct calculation will be useful: Code:
IIIIIIIIIIIIIIIIIIII
OOOOOOOOOOOOOOOOOOOO
I have seen awful results in almost all Windows application on my Yoga 2 laptop which has huge resolution. I had to lower my rez to 1/4th to have reasonable font sizes in menus and listboxes.
A problem deeper than LB or LBB.
Re: Typographical issues
Post by Richard Russell on Aug 12th, 2016, 10:29pm
Isn't it impossible to set the precise width of a textbox when you use a proportional font no matter how precisely and correctly you make your arithmetics.
As I said, setting the width precisely is a bad thing, because that's exactly what is likely to cause problems when the dialog is scaled. Rather, you want to be deliberately imprecise, in the sense of being generous with the space available for the text.
More generally, LB/LBB have the STRINGWIDTH? command which allows you to discover the width of a string even if you have selected a proportional-spaced font.
Incidentally a TEXTBOX is probably not a good example, because by default it will scroll horizontally and therefore its size is not so critical. I used the example of a STATICTEXT control because if the width is insufficient Windows will attempt to split the text into multiple lines.
Quote:
But if we use a non-proportional font like Courier than a correct calculation will be useful
Bear in mind that even so-called monospaced fonts aren't guaranteed to have all characters the same width. Some glyphs simply cannot be satisfactorily rendered the same width as the regular 'ASCII' characters. For example Chinese characters are likely to be in that category.
Quote:
I have seen awful results in almost all Windows application on my Yoga 2 laptop which has huge resolution.
That issue has largely disappeared in Windows 8 and Windows 10 because a high-resolution screen (with a DPI greater than 120) will by default be automatically scaled and will appear to the application program (e.g. LB or LBB) as a regular 96 DPI screen. For example my laptop has a 1920x1080 display but reports as, and behaves as, a 1280x720 display in LBB.
Quote:
A problem deeper than LB or LBB.
Thinking of it as a "problem" is part of the problem!!
Richard. Re: Typographical issues
Post by CryptoMan on Aug 13th, 2016, 06:50am
You are right, rather than problem, I think it is a fascinating topic.
Incidentally, Yoga 2 had more than 3000 pixels wide and came with Windows 8. It was a disaster. Did not change with Windows 10. But, is it a problem of the application or Windows? Probably, being lazy, programmers did not care for dynamic rendering and when resolution changed so dramatically, menu text became like micro print. I tried changing the settings from Windows by increasing the text size but could not find a satisfactory mix. So, a better resolution became a curse.
I have then encountered this issue when I developed a form generator for SQL where I wanted my text boxes in proportional spaces to SQL Field widths. I noticed my boxes as generously wider than I anticipated by chance because I was using (FontSize+1)*FieldSize. Now, I am realizing as I write, when we use Tahoma 14, the size means the height of the font but not the width. Therefore, we can estimate the height of the box but for width it is going to be much more complex. Arial Narrow and Tahoma will have different width needs.
So, unless we use a non proportional font like FixedSys, Courier, Consolas, etc with a Latin type language, we will never have our boxes showing precisely the size of the field on screen. Maybe, a max space according to the fattest glyph of that font.
Is it possible to get this size of max width of the fattest character in a given font and size? Say, something like, FontWidth('Tahoma',12,'O')?
Re: Typographical issues
Post by Richard Russell on Aug 13th, 2016, 10:44am
Yoga 2 had more than 3000 pixels wide and came with Windows 8. It was a disaster. Did not change with Windows 10. But, is it a problem of the application or Windows?
If the machine declares its DPI to Windows correctly, and if that DPI is higher than 120 (which it sounds as though it was) then the automatic scaling should come into play. The display should have been reported to all non-DPI-aware programs (which is the default) as 96 DPI and the Desktop Window Manager should automatically have scaled all output 'on the fly' to the native screen resolution.
I've seen that working correctly on multiple machines, and it's a godsend because it means the only DPI values you need to be aware of as a programmer are 96 and 120. If it was not working on your particular machine (and you had not deliberately disabled the high-DPI scaling) I would expect the problem to be the responsibility of the machine's manufacturer - perhaps the BIOS or graphics drivers - rather than Windows.
Quote:
Therefore, we can estimate the height of the box but for width it is going to be much more complex.
As I said, you have the STRINGWIDTH? command for that. It needs a graphicbox, but that can be hidden.
Quote:
Is it possible to get this size of max width of the fattest character in a given font and size?
Richard. Re: Typographical issues
Post by CryptoMan on Aug 15th, 2016, 6:36pm
Microsoft ruined my i7 Yoga2 so bad that I was forced to buy a i5 Acer couple of hours ago.
Yoga2 came with Windows 8 and after Windows 10 launched, Microsoft started pestering me for a Free Windows 10 Online Upgrade which I resisted for a year or so but finally I got fed up with it and said YES.
And, the result is total disaster. The battery which was lasting 4-5 hours started finishing in 30 minutes and after 15 minutes the screen started going dim with all sorts of static and horizontal and vertical sweeps. I replaced the expensive battery and no change.
Windows behaviour also got totally screwed up. Selected Windows remains in the background. You have to minimize all other Windows to bring the desired Window to foreground.
And, many other horror stories which finally ended up by buying a new laptop so that I can continue working.
The problems observed on Yoga2 with Windows 8 had 3200x1800 with Intel HD Graphics chipset.
I had problems on original Windows 8 at this resolution with Edraw Max software which I now tried on Ruined Windows 10 seems to be working properly which means something must have been fixed between Win 8/8.1 and Win 10. However, now that the Applicatıon behaves OK, the Legacy Windows Desktop icons became miniscule.
I have then adjusted the scale to effect from the main display settings page. Icons remained miniscule although showing a 250% scale.
Then I went to Custom Scaling ( not recommended ) and tried 400% and 300% too much and eventually settled at 200% scaling level which made Windows itself reasonable at this setting.
However, when I went back to EdrawMax to see what happened, unfortunately same old story, unreadable microsized text and Windows just as if they are taking the reciprocal of the scaling I am setting at Windows.
Now, I check uTorrent and that's fine. Paint.NET livable but icons and toolboxes now too small. PowerPoint ditto.
Our own MFC Windows apps fine.
Now, the acid test: LBB 3.04 : perfect.
Liberty 4.5 also perfect.
So, it seems that certain applications can manage it well and some applications do it not so good and in the case of EdrawMax, awful. Like I said, they must be taking reciprocals.
Enough time lost. Better go back to work on the new Acer.
Re: Typographical issues
Post by Richard Russell on Aug 15th, 2016, 7:14pm