The font sizes above 1.00em don't scale properly, as if using a different pixel size than those font sizes 1.00 and below. Actually, same for 0.90em. Only 0.95em seems to be correct.
The font seems to be at 6px, or maybe 50% of 12px. But the others seem to either cascade, where 1.25em is more than double 1.00em where it should only be 25% bigger and 2.00em is double.
Also, 1.05em and 1.10em are the same. Cascading is multiplying the previous values. Just to test my theory to 1.25em, let's multiply the previous values from 1.00em.
1.05 * 1.10 * 1.15 * 1.20 * 1.25 = 1.99 = DOUBLE
Can we fix this before we finalize 1.3?
I ran across this trying to predict the pixel width of the different font sizes. Works correctly for 0.95em and 1.00em, but blows up for the other values.
[1.3.b75] What's wrong with font size? Cascading Values!
Moderators: dorpond, trevor, Azhrei, giliath, jay, Mr.Ice, MapTool BugReport Manager
Forum rules
Posts that do not conform to the READ ME FIRST sticky thread are subject to deletion.
Posts that do not conform to the READ ME FIRST sticky thread are subject to deletion.
[1.3.b75] What's wrong with font size? Cascading Values!
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [1.3.b75] What's wrong with font size? Cascading Values!
Close. If the font size was set to 1.20em, the resulting font size used was 1.20*1.20*1.20 of the original size, so about 1.78*original. Using TinyLAF I have my default font set to 11pt so I was getting 19pt size.
Very good catch, alias.
Now the bad news... I can't fix this. It's a bug in the Java library. Specifically the CSS class.
MapTool creates an HTML string and surrounds the macro button with that HTML. It looks something like:
Of course, there are really two elements missing: an implied <body> and an implied <p>. Those elements are important because the bug is in how many layers deep the elements are nested. The HTML element inherits the font size of its parent (11pt), then body gets that * 1.20, then div gets that * 1.20, and finally the p gets that * 1.20.
The bug appears to be that the relative font size is being used at every level and not just the one where the font size is applied. This appears to be because in CSS a relative size for one element is based on the parent and the bug is that the parent is using the same (relative) size.
I haven't been able to find a bug report on this at the Java bug tracker site, but I've only been looking for a little while and I don't always use the right terms when I search there.
One fix (which I've implemented for the purpose of testing) is to change the relative font size to an absolute one. This allows the user to specify "11pt" or "15pt" to get a particular size. This seems to work without any errors. I also changed the font size field and the two color fields to be editable dropdown boxes, although the color boxes really should be ColorPickers but that's a lot more work. I need to check to make sure that the macros that create and/or modify MacroProperties will accept arbitrary colors but as I modified the low-level code to accept them I think it should be good.
I'll check the changes into SVN when I've done some more testing.
Very good catch, alias.
Now the bad news... I can't fix this. It's a bug in the Java library. Specifically the CSS class.
MapTool creates an HTML string and surrounds the macro button with that HTML. It looks something like:
Code: Select all
<html><div style="text-align: center; font-size: 1.20em; color: black;">(new)</div></html> The bug appears to be that the relative font size is being used at every level and not just the one where the font size is applied. This appears to be because in CSS a relative size for one element is based on the parent and the bug is that the parent is using the same (relative) size.
I haven't been able to find a bug report on this at the Java bug tracker site, but I've only been looking for a little while and I don't always use the right terms when I search there.
One fix (which I've implemented for the purpose of testing) is to change the relative font size to an absolute one. This allows the user to specify "11pt" or "15pt" to get a particular size. This seems to work without any errors. I also changed the font size field and the two color fields to be editable dropdown boxes, although the color boxes really should be ColorPickers but that's a lot more work. I need to check to make sure that the macros that create and/or modify MacroProperties will accept arbitrary colors but as I modified the low-level code to accept them I think it should be good.
I'll check the changes into SVN when I've done some more testing.
Re: [1.3.b75] What's wrong with font size? Cascading Values!
Cool. So, I was 1/2 right. Yeah, my calc did seem a little off and the high values make more sense. I actually already accommodated for the difference in my code, but having the absolutes will be better.
On a semi-related note, I'm curious about how you're going to do the colors. I know the font and background colors aren't all correct, at least to the HTML name codes. The background uses green, but is really lime. Also, aqua and cyan are the same color as well as silver and lt gray. Here's a list from my code to help me translate:
So, will we still have the ability to select a color name as well as edit the box?
edit: the 1.25 * 1.25 * 1.25 doesn't quite add up either for the result. That comes to 1.95, but I'm showing results for about 2.08, but the others add up correctly, so that must be right.
On a semi-related note, I'm curious about how you're going to do the colors. I know the font and background colors aren't all correct, at least to the HTML name codes. The background uses green, but is really lime. Also, aqua and cyan are the same color as well as silver and lt gray. Here's a list from my code to help me translate:
Code: Select all
[H: colorProps = "c.default=#ECE9D8; c.black=#000000; c.blue=#0000FF; c.cyan=#00FFFF; c.darkgray=#404040; c.gray=#808080; c.green=#00FF00; c.lightgray=#C0C0C0; c.magenta=#FF00FF; c.orange=#FFC800; c.pink=#FFAFAF; c.red=#FF0000; c.white=#FFFFFF; c.yellow=#FFFF00;"]
[H: fontColorProps = "fc.aqua=#00FFFF; fc.fuchsia=#FF00FF; fc.lime=#00FF00; fc.maroon=#800000; fc.navy=#000080; fc.silver=#C0C0C0; fc.teal=#008080; fc.olive=#808000; fc.green=#008000; fc.purple=#800080; fc.black=#000000; fc.blue=#0000FF; fc.gray=#808080; fc.red=#FF0000; fc.white=#FFFFFF; fc.yellow=#FFFF00; fc.default=#000000"]
edit: the 1.25 * 1.25 * 1.25 doesn't quite add up either for the result. That comes to 1.95, but I'm showing results for about 2.08, but the others add up correctly, so that must be right.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [1.3.b75] What's wrong with font size? Cascading Values!
Right now all you're going to get is a you-type-in-a-CSS-standard-color-string such as #40c040, for example. Once you use a particular color it'll appear in the dropdown list for other macros as well. The only bummer is that if you start typing it won't automatically scroll to that entry in the list -- that's more work.
Also, if you use setMacroProps and specify a color not already in the list it will be applied to the macro and will then appear in the list that's part of the UI.
I'm going to look at adding a color picker but we'll see how it goes.
Also, if you use setMacroProps and specify a color not already in the list it will be applied to the macro and will then appear in the list that's part of the UI.
I'm going to look at adding a color picker but we'll see how it goes.
Re: [1.3.b75] What's wrong with font size? Cascading Values!
How's that going to effect the current macros seeing that the props are set to color names? So, color names will not work at all?
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [1.3.b75] What's wrong with font size? Cascading Values!
Hm. That could raise issues in frameworks (at least ones like my recent ones that rely on macro button properties to get stuff done).aliasmask wrote:How's that going to effect the current macros seeing that the props are set to color names? So, color names will not work at all?
Don't get me wrong, I'm all for as much macro button color flexibility as we can get and welcome our multihued button overlords, but it may require rewrites here and there.
Re: [1.3.b75] What's wrong with font size? Cascading Values!
No, color names will still work. I guess I wasn't clear.aliasmask wrote:How's that going to effect the current macros seeing that the props are set to color names? So, color names will not work at all?
Anyone who has checked out the SVN code into Eclipse will see how it looks. Basically it works exactly as it did before: lots of color names (alphabetized now, and both web standard and Java standard color names are included in both lists).
The difference is that the field itself can be edited so that new colors can be added using the HTML #rrrgggbbb syntax (which most people shorten to #rrggbb since only 16-bit color is very portable). Any new colors that you type in are added to the list of color names (still in alphabetical order so all the ones that start with # will be next to each other in the list).
It won't affect getMacroProps nor setMacroProps at all AFAICT. My testing shows that both work just fine.
Technically the color names should be localized but that's too difficult in 1.3 and won't happen here. In fact, it probably won't happen in 1.4 unless it gets packaged into one of the UI updates.
Re: [1.3.b75] What's wrong with font size? Cascading Values!
Okay, that's good. I thought is was going to be purely #rrggbb. I'm guessing #rrrgggbbb is decimal?
I'm not sure what you mean by localized? Per client settings? language based?Technically the color names should be localized but that's too difficult in 1.3
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: [1.3.b75] What's wrong with font size? Cascading Values!
Language based. so Red to us to englishers is Rojo to our spainish friends, but if it comes back to one of us englishers on a token, it turns back into red (thats the "difficult part" according to Az)