FONTSAMPLER labelling fixed - ColumnMajor selectable

[MattHeffron]

Make the layout orientation, ColumnMajor or not, be selectable.
Fix the row/column labels to correspond to ColumnMajor selection.

Resolves #2408

[pamoroso]

I'm tested the this on Linux Mint 22.1 Cinnamon and I get the following order:

(FontSample (FONTCREATE 'MODERN 10 'MRR) 0 T 'DISPLAY)

(FontSample (FONTCREATE 'MODERN 10 'MRR) 0 T 'DISPLAY NIL T)

[nbriggs]

Better, but when I try

(FontSample (FONTCREATE 'HELVETICA 10) 357Q NIL 'DISPLAY)

I get a completely blank window. It doesn't produce any output until I have done a (FONTCREATE 'HELVETICA 10 NIL NIL 'DISPLAY NIL 357Q) after which time the font given to FontSample doesn't require the charset specification. Even with the same (new) font code, the old FontSample produced the correct result. If you give the new FontSample a list of character sets and the character set hasn't been previously instantiated it just ignores it -- for example

[nbriggs]

(by "the old FontSample" I mean the code as it existed in 1987)

[MattHeffron]

@nbriggs I believe I fixed the issue. If the font didn't have a SLUG charset, then comparing for it was eliminating unloaded charsets.

[nbriggs]

Why is it doing any checking for slugs? The original idea was that you gave it a font (or list of fonts) and a character set (or list of character sets), an optional printer name, and a stream type, and it lays out a sample sheet using the fonts that the system creates if those values are given to FONTCREATE and you get exactly what the printer would do if you were to use the font on output from any other program... where the "other program" is not going to be looking at slug info or anything else about the font -- just the basic font machinery. If you want to do something different how about naming it something other than FontSample and leaving my FontSample alone.

[MattHeffron]

Why is it doing any checking for slugs?

My thinking was that, with the new font mechanism, a FONTDESCRIPTOR can, after all of the character coercions that import glyphs from other fonts, state definitively that some character set(s) do not, and will not, have any glyphs, just slugs.
Displaying these character sets just seemed to be pointless.

Just now, I'm realizing that I have been thinking only in terms of DISPLAY fonts. It didn't occur to me that this wasn't correct for "printer" format fonts (e.g., INTERPRESS, PDF, POSTSCRIPT).
I can add a check that the slug-only character sets are excluded only for DISPLAY fonts.
Alternatively, I could add another argument to FontSample to indicate to filter out the slug-only character sets, defaulting to keep them.

[pamoroso]

I updated to commit 32c52cd which fixes the issue Nick reported.