It looks to me as though the HTML Text Trait fix has been dropped or messed up in the latest v3.4.0 snapshots… the one discussed on this thread-
…or will it just be re-included again when the next release is done ?
Mark
Snapshots are definitely a fickle mistress. It does very much depend. The text trait fix SHOULD be in 3.4!
Thus spake marktb1961:
It looks to me as though the HTML Text Trait fix has been dropped or
messed up in the latest v3.4.0 snapshots… the one discussed on this
thread-
Try VASSAL-3.4.0-SNAPSHOT-89e053500, which is the current 3.4 build. Do you
see the problem with that one?
–
J.
On further investigation, there is a problem/difference but it seems to be a different one. The test module for the previous bug still checks out ok.
However, in my actual module, I am seeing a much reduced font in the snapshots of v3.4.0 than in v3.4.0-beta1 and previous. The other attributes are ok. The format is driven by embedded HTML. I will develop another demo module.
Test module attached shows a reduced font size in Text Label output under v3.4.0-SNAPSHOT-89e053500 (and 6a21e841b) compared with V3.4.0-beta1.
The affected text has its font size set by embedded HTML. The bug does not manifest where the font size is set by the Text Label alone. However, if HTML is used to set the font size, the font size will be reduced and the Text Label setting does not over-ride this (so the HTML is having an effect).
The example module can be distilled to the following HTML which will show the symptoms in a Text Label:
“
Example Text”
Comparison to show how the bug manifests (example 4a is not affected because it does not set font-size in HTML):-
[attachment=0]text bug2.jpg[/attachment]
Just a quick update so you know we saw this. I tried reproducing it today with your test module, using both the snapshot you mention (89e053500) and with the “latest code” on the repo (both release & master branches), and was unable to repro on Windows. Joel had similar results on Linux. Presently waiting for the dev guy who has a Mac to see if he can get it to happen. Presently for the rest of us everything “looks like the left side” in all test cases.
Not sure this will help but I revised the test module to include the simplest demo of the problem.
Example 3/3a: Shows that several other text attributes are not affected, only font-size.
Example 4/4a: Shows the simplest form where HTML tries to set the font size (4; triggers bug) and the text label achieving the same effect, wherein HTML does nothing to text attributes.
In working around the bug, I have discovered that it is associated with setting a font in HTML using point-size. If I switch to pixels, the bug does not manifest.
I updated the demo model to show this (example 4b) - when the HTML text uses 32px rather than 24pt, the text appears correctly.
Fascinating. So you’re saying “px” dimensions are working correctly for you, and have been working in all the builds we’ve been discussing.
But “pt” dimensions are not working for you … but you’re saying they were working okay for you before?
Alas we have as yet been unable to reproduce your results at all on our machines using your test modules (including a VM Mac “Hackintosh”, but not yet an actual physical Mac as the one guys’ Mac just died). The earlier situation (that led to the “Text Label html fix”) repro-ed instantly for me 
Yes; to summarise, px works in all builds. “pt” works up to and including v3.4.0-beta1 but breaks in builds after that.
I will see if I can get some testing done on other machines.
Okay, have repro’ed successfully. Needed a retina display Mac.
Try VASSAL-3.4.0-SNAPSHOT-c1bc94ea8.
When rendering HTML, Swing doesn’t give us many knobs to turn, so sadly we can’t get crisper fonts by rendering at the actual size to be displayed. You should see the old behavior with this build.
Cheers Brian and Joel. Fix confirmed in VASSAL-3.4.0-SNAPSHOT-c1bc94ea8