Increase display area before reducing font size to fit more digits in display.

[JohnHind]

Is your feature request related to a problem? Please describe. It is hard to read numbers once the font size gets too small and it is not making best use of available screen space.

Describe the solution you'd like When 'Enable Window' is unchecked in settings, the display area should be widened to the full width of the keyboard and font size reduction should only commence once this wider space has been consumed.

Describe any alternatives you've considered When 'Enable Window' is checked, it could be enabled to allow the display to be dragged left and right and the standard Android dots indicator shown to indicate which chunk is displayed. I rejected this because I understand you are aiming for maximum fidelity to the original calculator. However with 'Enable Window' unchecked the user has elected to depart from fidelity for usability, so you may as well make other changes to maximize utility.

Additional context It is my contention based on the logic of the industrial design of the Voyager calculators that the original designer would have liked to use a screen that filled the entire area above the keyboard, but was forced to compromise for cost or technical feasibility reasons. I believe it is in the spirit of the original design to at least provide the option of doing this in a modern emulation now this barrier is irrelevant. In addition to allowing a wider numerical display, this would allow two or even three stack rows to be displayed, an innovation that would be entirely consistent with the later evolution of HP RPN calculators in the portrait format.

[zathras]

Good points, all. I can see how this would make the calculator more pleasant to use, particularly in today's 64 bit world.

To tell you the truth, I saw the "window disabled" mode as more or less a cute gimmick that was easy to implement, and maybe a little bit useful for, say, longish-hex numbers. But with even a 64 bit hex number the 7 segment digits get pretty small, and it shouldn't be too hard to take over some of that silver space on either side. I guess I could even go ahead and cover the logo plate on the right.

It might be a little jarring for some to see the display grow and shrink like that with the size of the number, so I guess the "enable window" setting should be a trinary: Enabled, disabled, and disabled/expand, or something like that.

Are you set up to build from source? And if not, what platform are you on? I might want to play around, and see what you think before I spin a whole binary release.

[JohnHind]

I can test on Windows, macOS and Android (I am able to install an APK file on my Android devices). I am willing to set up a build environment on Windows if it is reasonably straightforward and well documented though I am not familiar with Flutter or Dart and may not have the bandwidth unless it is really straightforward - these things can be a real rabbit hole!

I agree that a dynamically sized 'virtual LCD' could be distracting. My suggestion would be to simply expand the visual LCD 'window' to full keyboard width whenever 'window disabled' is checked: the actual digits do not have to fill the visual window for shorter word widths.

[billf-pshs]

OK, well, I can just make a binary. Flutter's not too difficult to set up, but it can drag in gigabytes worth of stuff. Would shipping over a self-signed APK work for you?

It might be a few weeks before I really look at this.

(Oh, this is the same person as "Zathras," just from the github account at work.)

[billf-pshs]

I played around a bit with the visuals. There are two competing imperatives here...

• Having a display size that jumps around all the time seems like it would be jarring
• A wider display is uglier

The second one argues against keeping it wider whenever disabled is checked. Here's what I'm thinking: I could expand it to be big enough to fit the biggest possible number, given the current number of bits and display base. That way, the LCD would only change size when you change the number base, or change the number of bits (WSIZE). That keeps the UI pretty if you're in e.g. 32 bit hex mode, or floating point mode. (I'll have to check, but I think the maximum float number with ten digits of precision would just require space for three more digits, and that should still be pretty.) In 32 bit decimal mode it would be a little wider, and in 64 bit hex mode it would hit max width.

Here's what it looks like when I expand the LCD size to be exactly big enough for a 16 digit hex number, that is, the max WSIZE of 64 bits, and still maintain full size of the digits:

It's certainly more usable, but IMHO it's a little ugly; if that width isn't needed for the current WSIZE, I personally prefer prettier :-)

Beyond 16 digits, I'd be forced to scale down the digits, so of course a 64 bit binary number still looks silly:

I guess I could scale down half as much and put it on two lines or something like that, but these days it seems to me like most people would use hex just about all the time. Anyway, reading 64 bits of binary is pretty horrible, no matter how it's displayed!

Oh, and of course, this only applies to the landscape layout. In portrait, there's not much to be done (unless it goes to two lines). But landscape really is the preferred orientation -- I keep mine locked to landscape on Android.

I guess I could add an "Expand LCD" setting that'd disabled if "Window" is enabled. Squeezing a drop-down into the menu seems like it might be a stretch.

Does this all look reasonable to you?

[JohnHind]

I guess beauty is in the eye of the beholder, personally I think this width looks much better and even you could cover the logo maybe just putting ‘16C’ part below the display window! You do not have to fill the display window all the time, and maybe could still justify it left to keep fairly close to the aesthetics of the original. But adapting the width to the WSIZE and base would satisfy me too.

Not wishing to cause scope creep, but definitely I think expanding to two lines for the binary display would be better and it would also be improved by being visually separated into chunks of four or eight digits with spaces or commas. When in decimal mode (standard calculator) I like the idea of using the two rows to show both the X and Y stack levels.

PS: I agree about landscape: the portrait display is, in any case, inauthentic. I think the Voyager format is a thing of beauty and you render it beautifully! But I do think it is improved by having the display fill the space above the keyboard which looks to me to follow the design logic. Maybe your preference comes from familiarity?

------ Original Message ------ From "Bill Foote" @.> To "zathras/jrpn" @.> Cc "JohnHind" @.>; "Author" @.> Date 18/09/2023, 10:17:43 Subject Re: [zathras/jrpn] Increase display area before reducing font size to fit more digits in display. (Issue #58)

I played around a bit vit the visuals. There are two competing imperatives here...

Having a display size that jumps around all the time seems like it would be jarring A wider display is uglier The second one argues against keeping it wider whenever disabled is checked. Here's what I'm thinking: I could expand it to be big enough to fit the biggest possible number, given the current number of bits and display base. That way, the LCD would only change size when you change the number base, or change the number of bits (WSIZE). That keeps the UI pretty if you're in e.g. 32 bit hex mode, or floating point mode. (I'll have to check, but I think the maximum float number with ten digits of precision would just require space for three more digits, and that should still be pretty.) In 32 bit decimal mode it would be a little wider, and in 64 bit hex mode it would hit max width.

Here's what it looks like when I expand the LCD size to be exactly big enough for a 16 digit hex number, that is, the max WSIZE of 64 bits, and still maintain full size of the digits:

Screenshot 2023-09-18 at 4 55 33 PM https://user-images.githubusercontent.com/134981727/268599300-0a4f3136-e3af-4c93-8391-935a5f767f3a.png It's certainly more usable, but IMHO it's a little ugly; if that width isn't needed for the current WSIZE, I personally prefer prettier :-)

Beyond 16 digits, I'd be forced to scale down the digits, so of course a 64 bit binary number still looks silly:

Screenshot 2023-09-18 at 4 56 06 PM https://user-images.githubusercontent.com/134981727/268600049-7b8a63dc-4df7-4e84-94de-6f96d8da722e.png I guess I could scale down half as much and put it on two lines or something like that, but these days it seems to me like most people would use hex just about all the time. Anyway, reading 64 bits of binary is pretty horrible, no matter how it's displayed!

Oh, and of course, this only applies to the landscape layout. In portrait, there's not much to be done (unless it goes to two lines). But portrait really is the preferred orientation -- I keep mine locked to portrait!

I guess I could add an "Expand LCD" setting that'd disabled if "Window" is enabled. Squeezing a drop-down into the menu seems like it might be a stretch.

Does this all look reasonable to you?

— Reply to this email directly, view it on GitHub https://github.com/zathras/jrpn/issues/58#issuecomment-1723035808, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATDYNRZBKDTGUVZ42VAONTX3AGTPANCNFSM6AAAAAA426WI34. You are receiving this because you authored the thread.Message ID: @.***>

[billf-pshs]

Oh, you can already put commas in, every four digits (in binary/hex/octal), and every three digits in decimal. Settings -> Integer Mode Commas. Actually, they used to always be there, but then someone pointed out that the real 16C doesn't display commas in the integer modes, so I made it a setting that defaults off. I was surprised that the original 16C didn't put commas in like that.

Yeah, looking at the display I guess there's value in having two lines in binary mode. And come to think of it, maybe I just imagine someone using it that way, like for an Arduino bit controller - visualizing binary from a hex number is perhaps a disappearing skill these days :-) I guess I could just have two line mode kick in whenever the number of bits goes over 32.

[JohnHind]

Missed that you could scroll the settings menu for more settings! Commas look good, but of course extend the length further. There is a tradeoff between font size and number of rows. At minimum legible font size there would be plenty of room for even four rows if necessary. How about a three pronged attack: first increase the window width as much as possible, then reduce the font size down to the minimum reasonably legible size, finally wrap onto as many rows as reasonably fit onto the screen height. This approach would work for the portrait mode too: less width but more height so potentially more rows.

[billf-pshs]

Actually, the commas don't increase the length. It's simulating a 7 segment LCD display, so it just turns on the comma segments. It's not using a font - it's drawing the display with graphics primitives. It was fun working out the trig for that, honestly. Indeed, that was the thing that kind of hooked me into doing the rest of the project. The trig's at https://jrpn.jovial.com/dartdoc/view.lcd_display/Segments-class.html , if you're curious.

Anyway, yes, I'm suggesting stretching the display (which fits 16 digits without decreasing the font), then shrinking down the digits up to 32. Over 32, it would add a second line. That's a little less than a 50% size reduction of the digits, which should be reasonably legible. Anyway, I'll hack in those numbers to start, and see how it looks.

Let's see... the size at 32 digits would be (16 + 2) / (32 + 2), because " b" takes up the same space as two digits, so the digit size would be 53% of full size.

[billf-pshs]

FYI, here's what a 32 bit binary number looks like. The LCD is sized so that a 16 bit number would fit with full-sized digits. I need to scoot it down some, so that there's room for the line that can hold the 32 most significant bits. I'm pretty happy with this. I could maybe make the digits as much as 60% of full size if I did something about the icon, but shooting for 16 bits at full size seems like a good tradeoff, and at 60% I might run out of vertical space, when you figure in the annunciators.

[billf-pshs]

Hi John,

I don't have two-line display implemented, but the rest it there. Here's a debug Android APK you can try out... https://drive.google.com/file/d/14UOhP7tLubrgeZmnc4-MX8OcHSPlxi5q/view?usp=sharing

[JohnHind]

Thanks Bill!

I got this installed on my Google Pixel 7 Pro phone with no problem. It is looking good and personally I think the wider display looks great. I am glad you do not alter the aspect ratio of the overall landscape rendering because I do think the Voyager aspect ratio is important to its aesthetics. However I do think you could make the portrait version taller to accommodate more display rows. On both renderings, perhaps the menu dots could be justified top right of the display rather than on the rendering since this is part of the emulator rather than the emulated device?

I do have a use case for large binary numbers. I do a lot of microcontroller work and some device drivers. It is common to pack a number of one bit flags, two or three bit enumerations and say 8 or 12 bit integers (to match an ADC or counter resolution for example) into a single register (usually 8, 16 or 32 bits wide, but 64 may become more common in the future). It is useful to be able to construct these in binary and then convert to hex to make masks etc. Another case is low-level communications protocols. So I'd encourage you to do wrapping onto multiple lines as well if you can, and this also has the advantage of working automatically with the portrait rendering.

Slightly off topic, I wondered if you were aware of this: https://www.thecalculatorstore.com/epages/eb9376.sf/en_US/?ObjectPath=/Shops/eb9376/Products/%22HP-15c%20%23INT_2%22 There are also the SwissMicros ones of course, but this looks a little more appealing and authentic, although less functional (no USB connection for example).

[zathras]

This all made me realize I should write a user guide, particularly for some of the less obvious menu items. See https://jrpn.jovial.com/help.html

About the menu dots, I usually just get rid of 'em with the setting. The menu is in the standard place, so I figure once someone finds the menu setting that turns them off, they no longer need the dots.

For portrait, I'll see if I'm happy with how two lines looks in landscape before I think too hard about that. It could be worth doing. I guess in binary I'd want to shrink the digits down to where a 16 bit binary number fits in one line first, then start adding lines, up to a max of four. That could be OK. 8 lines of full-size digits with 8 bits per line seems a bit much. Hmmm.... By doubling the LCD height, I could fit a 64 bit hex number in two lines of full-sized digits, which seems reasonable. In octal and decimal it wouldn't take much shrinking, and in binary about 50% would do, which seems like it would be OK.

Thanks for the link to the 15C hardware. If the one I bought at the UCLA student store in the early '80s ever gives out, I'll know where to go!

BTW, I'll be on various trips for a couple of weeks, and hopefully doing enough sightseeing so that I'll put this aside for a bit :-)

[zathras]

FYI, this has been published as a beta in the Google app store, and released on Linux and Windows. I'll be doing the Github release soon. I'm pretty pleased with how it turned out, even in portrait mode -- thanks for the suggestions!

[JohnHind]

This looks great - very nicely done!

Personal preference, but if it were me, I'd make 'LCD Size' one option with selections 'Large' or 'Standard' and 'Long numbers' separate with options 'Window' or 'Shrink Digits'. The large LCD would be large always with the 10 digits or less font increased in size and you could opt for Large LCD and still opt for Window for long numbers. But just a possibility for consideration, I am very happy with what you've done already!

Another nice enhancement (but not one I'd personally use) - in 'Window' mode allow the display to be swiped left or right to move through the windows and maybe add an indicator to show where the window is in the overall number (a scroll bar or a row-of-dots-with-one-filled-in indicator like Android uses). But maybe not worth it unless is is easily implemented!

I've been playing with my new 15C Collector's Edition, and was surprised by the depth and elegance of the software as well as the hardware. Also in awe of the amount of effort you have put in to re-implement it all! It strikes me there are large screen improvements you could make to your 15C emulator too. For example, you could show both real and imaginary parts of complex numbers simultaneously in a wider display.

[zathras]

Thanks!

Personal preference, but if it were me, I'd make 'LCD Size' one option with selections 'Large' or 'Standard' and 'Long numbers' separate with options 'Window' or 'Shrink Digits'. The large LCD would be large always with the 10 digits or less font increased in size and you could opt for Large LCD and still opt for Window for long numbers. But just a possibility for consideration, I am very happy with what you've done already!

I guess, but I think the normal font size is pretty legible as it is.

Another nice enhancement (but not one I'd personally use) - in 'Window' mode allow the display to be swiped left or right to move through the windows and maybe add an indicator to show where the window is in the overall number (a scroll bar or a row-of-dots-with-one-filled-in indicator like Android uses). But maybe not worth it unless is is easily implemented!

That would be a fair amount of work. I'm not using a standard widget or anything like that were I could just turn that on -- in order to get the exact look of an LCD, I'm doing all the drawing myself.

I've been playing with my new 15C Collector's Edition, and was surprised by the depth and elegance of the software as well as the hardware. Also in awe of the amount of effort you have put in to re-implement it all! It strikes me there are large screen improvements you could make to your 15C emulator too. For example, you could show both real and imaginary parts of complex numbers simultaneously in a wider display.

Yeah, the 15C is an amazing bit of engineering. When I started on the 15C, I thought it would be comparable to the 16C, but it's a lot more sophisticated.

It would certainly be possible to do real and imaginary numbers as you suggest, and maybe a more meaningful display of matrices. But that's going in the direction of making a different calculator -- and there are already better RPN scientific calculators than the 15C, with existing emulators. For example, the 48G is pretty good.

Extending the display, essentially for big binary numbers makes sense to me, since it's such an obvious annoyance that doesn't really change the nature of the calculator. Actually using window mode seems like it would be pretty painful! But much beyond that, and I'd be retracing the development of calculators into the '90s and '00s, and, well, that's been done already :-)

Cheers,

Bill