For years, I used to use the 80-column text screen on the old Apple II as displayed on an AppleColor monitor (either the composite one for the IIe or the analog RGB one for the IIGS) as the metric for minimum readability for text.

However, in recent years nobody knows what I'm talking about when I say "If it's smaller than the 80-column text screen on an Apple IIe it's too small". Or if they have an idea what an Apple IIe is, they don't know what the text looked like.

Could somebody suggest a better way to talk to the next generation too young to remember the Apple II? I'm not sure the best way to describe the text size on an Apple II.
The context is something like talking about say the text in the Battletech game from Harebrained Schemes / Paradox Interactive, or how a web page is rendered on my phone and being annoyed at how small the "Mobile friendly" version appears, especially if I try to zoom and the site forces me to use horizontal scrolling.
We had Word Wrap on the Apple II+ with DogPaw and numerous other programs for god's sake, why can't a phone with a processor 40 years more advanced do simple word wrap?

I would say, don't talk about 40 col or 80 col text. Just tell them the size of the computer screen was really small back in the day. Then show them the IIc monitor or a picture of. Kids these days are too used to using 65 inch tv's hooked up to their computer. I don't know how I ever worked without one. I have a 42 inch hooked up and now I can sit 20 ft back and still be able to read the text.

On 2022-01-21 21:53:15 +0000, Slick RCBD said:

> For years, I used to use the 80-column text screen on the old Apple II
> as displayed on an AppleColor monitor (either the composite one for the
> IIe or the analog RGB one for the IIGS) as the metric for minimum
> readability for text.
>
> However, in recent years nobody knows what I'm talking about when I say
> "If it's smaller than the 80-column text screen on an Apple IIe it's
> too small". Or if they have an idea what an Apple IIe is, they don't
> know what the text looked like.
>
> Could somebody suggest a better way to talk to the next generation too
> young to remember the Apple II? I'm not sure the best way to describe
> the text size on an Apple II.
> The context is something like talking about say the text in the
> Battletech game from Harebrained Schemes / Paradox Interactive, or how
> a web page is rendered on my phone and being annoyed at how small the
> "Mobile friendly" version appears, especially if I try to zoom and the
> site forces me to use horizontal scrolling.
> We had Word Wrap on the Apple II+ with DogPaw and numerous other
> programs for god's sake, why can't a phone with a processor 40 years
> more advanced do simple word wrap?

I don't know about describing it, but if you've got a Mac then you can
show them ... the Terminal app's preferences can be set to be 80
columns wide x 24 rows high, or any other size you want.

TL:DR; Font size should be 20+ pt on mobile devices.

> "If it's smaller than the 80-column text screen on an Apple IIe it's too small".
> Could somebody suggest a better way to talk to the next generation too young to remember the Apple II? I'm not sure the best way to describe the text size on an Apple II.

You are not alone with text being too bloody small on mobile devices. You'll want to discuss this with reference to font point size for readability. This means you'll probably also need to get into physical device measurements and dpi.

For example, measuring my Apple //e monitor I see it is 11" x 7.5". The actual displayable area is 9"x7". This gives these metrics:

* horz 9" / 560 px = 0.01607 inch/px (or 62.22 dpi)
* vert 7" / 192 px = 0.03645 inch/px (or 27.43 dpi)

Now that laughably "Low Res" compared to today's retina displays of 400+ dpi but it is a useful metric for when a font size becomes too small. On a 80x24 text screen each glyph is 7x8 px. This corresponds to these physical dimensions:

* 7px * 0.01607 inch/px = 0.1125 inch
* 8px * 0.03645 inch/px = 0.2916 inch

Converting that back into point size:

* 0.1125 * 72 = 8 point
* 0.2916 * 72 = 21 point

Thus anything less then ~21 point size on a phone will start to run into readability issues.

I designed the world's smallest font with 2x2 pixels for lowercase.
https://github.com/Michaelangel007/nanofont3x4

For that project I also made a 640x1136 px image with this nanofont font to match the native resolution 1:1 on my iPhone 5 to see how unreadable it was. Turns out it was readable (barely) but this was when your face was on top of the phone.
https://raw.githubusercontent.com/Michaelangel007/nanofont3x4/master/pic/output_bold_sources_ken.png

I haven't updated this for the new iPhones but I probably should as then you could link to it and say "See, THIS is too small."

> The context is something like talking about say the text in the Battletech game from Harebrained Schemes / Paradox Interactive, or how a web page is rendered on my phone and being annoyed at how small the "Mobile friendly" version appears, especially if I try to zoom and the site forces me to use horizontal scrolling.

The worst is these stupid "mobile" versions that don't let you shrink or expand the web page when you pinch / unpinch! On desktop we can use Ctrl+MouseWheel to zoom a browser scaling which works great. This same functionality isn't always available on mobile devices which further exacerbates the problem.

> We had Word Wrap on the Apple II+ with DogPaw and numerous other programs for god's sake, why can't a phone with a processor 40 years more advanced do simple word wrap?

Because that would take "work". /s

Seriously, programmers and designers have gotten extremely lazy. Make the computer easier to use for people? Nah, designers would rather fuck around with the UI, flat shading everything so you can no longer tell what is clickable, and what isn't, and CONSTANTLY change the UI trying to justify their jobs. It truly sucks.

Hell even an Apple ][ is more responsive then todays machines.
https://www.extremetech.com/computing/261148-modern-computers-struggle-match-input-latency-apple-iie

Michael

On Friday, January 21, 2022 at 1:53:16 PM UTC-8, Slick RCBD wrote:
> [...] how a web page is rendered on my phone and being annoyed at how small the "Mobile friendly" version appears, especially if I try to zoom and the site forces me to use horizontal scrolling.

Part of the problem is that the web site has no idea how big your screen is..

While updating my site for Responsive Web Design, I learned that you're supposed to define multiple layouts, and choose between them based on the reported width of the display device. There's no official standard for what constitutes "small" vs. "medium" vs. "large", but there are some agreed-upon values. If you visit https://6502bench.com/sgtutorial/moving-around.html with a desktop browser and resize your window, you can see the layout changing as the window width hits 600px, 768px, and 992px. (These are, sadly, referred to as "breakpoints".)

The part where things get messy is when dealing with mobile devices, because you want the layout to be based on the width of the device. A 6" phone should be laid out differently from a 10" tablet, and should be different for landscape vs. portrait. The trouble is that the Responsive Web Design CSS layouts are based on pixels, and pixel counts vary significantly because of DPI differences. A phone's display might be 2560x1440, but you wouldn't want to lay the page out the same way you would a 27" monitor with the same number of pixels.

To make this work, the phone manufacturers have to lie about the number of pixels reported by the browser. They have to pick a pixel count that yields the desired layout, and scales fonts to be readable. If they choose poorly, you can end up with too much or too little on the screen at once. The fact that there isn't an official set of guidelines for what to do at various resolutions makes the whole thing a little dodgy. The web site developers are trying to guess what the phone manufacturers are reporting so their web pages look good, and the phone manufacturers are trying to guess what the web developers are using for breakpoints so their devices look good.

My main issue with "show them X", is that when I'm talking about these things in person, I don't have access to Macs or Apple II equipment. I've got to use my words. At best I might be able to call up something on my phone, but that runs into the scaling issue. I can only show the text on my phone and say "if it's smaller than this, it's too small".
However other times I might be posting on a message board or sending an e-mail, so I'd have to link, with no way of knowing if it would appear the same on their screen as on mine. So again, I'm unsure how to describe to them the size of the text on the Apple II 80-column screen.
BTW, I didn't notice much difference back when I was a kid between that smaller green monitor, the Apple IIe's color monitor, my Apple IIGS's color monitor, and the older brown color monitor I occasionally saw in school with a IIc or pre-platinum IIe. I think each of my schools only had ONE IIc.

Another issue I have is that in the 1990's, before CSS with it's fixed layouts became king, websites were designed so that if you changed the size of the window, the text would rewrap to fix the new window. The window was supposed to be resizable. It was also supposed to let the user pick the font sizes and initially you could only specify things like "larger" or "smaller" via the headings tags, with H3 being standard size, H1 and H2 being larger and H4, H5 being smaller. I absolutely hated when the FONT SIZE tag was introduced because everybody seemed to like tiny text, although I later found out that IE handled the numbers differently from Netscape so it wasn't as bad in IE.
Now sometimes you ran into problems making the window smaller than 640x480, later 800x600, but usually this worked.
What would be nice is if when I zoomed the page to make the text bigger, the text would automatically rewrap to fit the new viewport.

On Monday, January 24, 2022 at 6:45:10 AM UTC-8, Slick RCBD wrote:
> My main issue with "show them X", is that when I'm talking about these things in person, I don't have access to Macs or Apple II equipment. I've got to use my words.

Take a picture of the Apple II monitor with text and favorite that photo so you can quickly show them a sample reference image?

Michael

Personally, I have used actual point sizes as they appear on the screen.

One can break this discussion into two components:

Point size. Print out, or use a reference document and compare actual text size. Say 10pt on the ref document compared to the displayed text being larger or smaller.

The other component is DPI, dots per inch as was calculated above.

For a given display, there will be a floor where the DPI is not sufficient to render the font glyphs with enough fidelity to be useful. An Apple 2 has basically two DPI numbers. One for the 40 column text and HGR, and a sort of higher one for 80 columns and DHGR. Both are the same vertically.

On the other extreme, a mobile will have a much higher DPI, and can display much smaller glyphs.

Simply give them a reference text size on a printed document and or maybe a couple, just enough to compare the intended cases and no more.

They can literally hold that up to a display and adjust the font parameters on it, until it is good to go.

Display size makes this all hard, and I tend to just get physical references and or point to ones I know most people can find and make adjustments from there.

You can do this with a nice sans serif font, monospace type, and print out font at 10, 12, 14, 16pt and pick out your Apple 2 text size you like and convert it to a physical point size and be good to go talking about it to others.

About the only way it goes bad is when the desired physical size is too small for the DPI of a device. In that scenario, either get the display farther away, lolol, or use a larger reference size to account for that display and DPI. Given you want to specify text size on newer stuff than an Apple 2, you should not run into this problem and need only to associate Apple 2 40, 80 column text to an physical point size and monospaced sans serif font and be good.

> One can break this discussion into two components:
> Point size. Print out, or use a reference document and compare actual text size. Say 10pt on the ref document compared to the displayed text being larger or smaller.
> The other component is DPI, dots per inch as was calculated above.

Point Size is a good idea.

Another strategy would be to print a 80x24 grid on transparency film paper. (One can use a laser printer or inkjet printer.)

That way you can move this transparent grid closer, or further back, to get the right amount of scaling that shows where there is too much whitespace, too little whitespace, fonts are too small, or fonts are too big.

Michael