Font for summation index is too large in Discrete screen.

[pixelzoom]

For #178 ...

In #156, we made the infinity symbols larger for summation and integral in the Wave Packet screen. Either in that issue or (more likely) in #165, the range for the summation got a little too larger, see screenshot below.

I'm going to reduce the font size in the Discrete screen, while being careful not to change the Wave Packet screen.

[pixelzoom]

Fixed in the above commit.

Index font for the Discrete screen is now smaller (12 pt), as it was originally:

Wave Packet screen is unchanged from the sizes that were approved in #156. (Note that the 'n' is larger because we do not have separate control over the 'n' and infinity symbols. See #156 (comment).)

@arouinfar please review in master.

[arouinfar]

Looks good, thanks @pixelzoom.

[kathy-phet]

@pixelzoom - If you are pixel polishing this, should we make the "n =" part under the summation the same size on both screens? The discrete the n= is smaller than on the Wave Packet. I like the size of the "1" the "11" and the "infinity symbols". The "n=" could be either of the two sizes, but seems like it should be the same on both screens. I perhaps have a slight preference for the slightly larger version of "n=", but no terribly strong. I like the new size of the "1" and "11" over version v.48.

[pixelzoom]

What you've described is not currently possible. The sizes are a compromise, and that compromise (and the reasons for it) are described in #156 (comment). After re-reading that comment, let me know if you'd like me to pursue reimplementing the summation/integral Node.

[kathy-phet]

No need to reimplement. I can certainly be fine with what's there ... just noticed the difference.

[pixelzoom]

Yeah, I notice the difference too - and it bothers me. So I'm going to reopen this (again :) and take another look.

[pixelzoom]

In the above commit, I broke the "n = {{minValue}}" into 2 separate parts: "n =" and "{{minValue}}". The table below shows the things that have separate font sizes, and what their current font sizes are. And to be clear, this is just for the summation/integral symbol part of the equations.

component	font size
∑ and ∫ symbols	30
'n = '	14
range numbers, like '1' and '11'	12
∞, -∞	16

Examples:

I'm glad I did this - it makes me happy.

What still makes me a little sad is the vertical alignment of 'n' and '=', '-' and '∞'. I have no control over that, it's how scenery is rendering the strings and aligning their baselines. I'd have to render each character/sign separately, and adjust their positions empirically. That would be ill-advised because it would be specific to one font, on one platform. So I'll leave it there, and try to ignore it.

@kathy-phet @arouinfar please review in master, and let me know if you'd like to tweak any of the font sizes in the above table.

[kathy-phet]

Chris, this looks nicer. Thanks! I assume you can’t center align them vertically, so it depends less on the rendering. Just a thought.

…

Sent from my iPhone

On Sep 27, 2021, at 7:21 PM, Chris Malley ***@***.***> wrote:  In the above commit, I broke the index minimum into 2 separate parts: 'n =' and '0' (or -infinity). The table below shows the things that have separate font sizes, and what their current font sizes are. And to be clear, this is just for the summation/integral part of the equations. component font size ∑ and ∫ symbols 30 n = 14 range numbers, like '1' and '11' 12 ∞, -∞ 16 Examples: I'm glad I did this, because this makes me happy. What does not make me happy is the vertical alignment of 'n' and '=', '-' and '∞'. I have no control over that, it's how scenery is rendering the strings and aligning their baselines. I'd have to render each character/sign separately, and adjust their positions empirically - and that would be ill-advised because it would be specific to one font, on one platform. So I'll leave it there, and learn to ignore it. @kathy-phet @arouinfar please review in master, and let me know if you'd like to tweak any of the font sizes in the above table. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[pixelzoom]

No, I can't center align them vertically. I have no control over any form of vertical alignment (center, baseline,...) unless I render each character as a separate Node, then move them around empirically. And that empirical adjustment (as I said above) would be specific to one browser/OS, because of differences in how fonts are rendered. So I could only make it look "perfect" on exactly one browser/OS, possibly to the detriment of other browsers/OS's.

@arouinfar feel free to close if this looks OK to you.

[arouinfar]

Looks good to me, thanks!