SizeOf: Screen, TextFrame, Font.

If "A" is 7 pixel wide does this mean that a higher-resolution display shows smaller chars?

It's a problem to set the font-size, applicationFrame-size. And then there's X and VT modes.

wily: a remarkable utility [based on ETHOberon] which allows you to access multiple TextFiles on the same screen, gave me problems on both PC & rPi. Some text-line-parts displayed blank. And I couldn't get a reply to my cries-for-help. In both cases the solution was simple: klik wily's button. What's the THEORY behind this? ========== put after main questions. Now that we've got a basic-ETHOberon for rPi, let's extend & refine it. For those who don't want to be limited to using pre-served applications: [rPi was intended to be educational; not just another dumb-consumer product] what's the formal relationship between sizes of Screen, TextFrame, Font.

OK, under ETHOberon the font is constructed/edited: yes you can edit any of ETHO's fonts, so that "A" displays a bird, or char(N) displays a BIG JuliusCeasar!

But, playing with the font editor, is not our first priority. I'm going to just copy some code from more mature versions of ETHO, to get: Load & Store TexFiles in *nix format, and perhaps FAT too. We need to be able to Read/Write Linux files with ALO.

The version of ALO that I'm using is alo_140423.tgz 842'034 Bytes My log shows: curl -O \

formatting link
which version I'm also using.

I needed to install to execute `xhost +`, before ./alo to install/run. We are not yet clear what that's about. Personally, I'd prefer a FrameBuffer, rather than X version, of ALO; as indeed Peter Matthias has made for x86:LinuxNativeOberon. But we need extra collaborators.

Reply to
Loading thread data ...

On Sun, 4 May 2014 04:51:14 +0000 (UTC), declaimed the following:

In general (not OS specific), if it is a bitmap font that is truly 7 pixels wide, then yes -- a higher resolution (in DPI) display will show smaller characters; if that higher resolution display is also physically larger, it could go either way.

If the font is a scalable type (PostScript, TrueType, OpenType, Compugraphic, etc.) in which the measurement was 7 /points/, AND if the OS is properly configured with the display DPI and dimensions, I'd say no -- the rendering system should properly scale the font glyph to retain 7 point width, whether that takes more or fewer pixels on the actual display.

	Wulfraed                 Dennis Lee Bieber         AF6VN    HTTP://
Reply to
Dennis Lee Bieber

'point' is HEIGHT not width and is 1 point = 1/72 inch.

Width is detemined on monospace by constant ratio of height to width

Width on proportional character sets, well each character has its own width which gives rise to the other measurements which are width of character - el, em, en and ex.

Paul Carpenter          | 
    PC Services 
 Click to see the full signature
Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.