Need Font::setPointSize (float sizeInPoints);

Don’t thank me just yet…setting “#define JUCE_USE_DIRECTWRITE 0” causes this result:

[attachment=0]JuceDemo.png[/attachment]

Drat… I definitely tested that!

Did you test it before or after you changed the Font listbox to use withPointSize() instead of setHeight ()?

Did you test it before or after you changed the Font listbox to use withPointSize() instead of setHeight ()?[/quote]

I obviously tested it just before I broke it.

Let me see if I understand this right (at least, on Windows).

When you load a font you set the point size to -256. Then when loading glyphs you normalize the outline by scaling it by a factor of 1/tm.tmHeight where tm is from TEXTMETRIC?

Why 256 is that an 8-bit fixed point number equal to 1.0? Or are you just using a large size?

I think that on Windows you’re missing a conversion based on the device context’s DPI (which is 96 not 72).

From MSDN:

// you can use the following formula to specify a height for a font with a specified point size:
lfHeight = -MulDiv(PointSize, GetDeviceCaps(hDC, LOGPIXELSY), 72);

Thanks Vinnie - leave it with me, I’ll get it sorted out…

Looks great now, with DirectWrite enabled. The heights match the output of fonts in other Windows programs. There’s a little discrepancy with the x offsets but I think thats more related to layout, kerning, and hinting instead of glyph scaling.

Unfortunately, some fonts don’t show up when DirectWrite is turned off (although the ones that do show up appear correct). I’m not sure if this a regression, the fonts don’t appear in the preview pane either:

[attachment=0]JuceDemo.png[/attachment]

Vinnie,

Did you test it with the Sonata font? If so, how did it look?

I don’t own the font, so no

AloisenNew looks good:

[attachment=0]JuceDemo.png[/attachment]

I hate to bring it up but the lack of hinting is pretty severe with music fonts. Fortunately VFLib provides a solution.

[attachment=0]Hinting.png[/attachment]

The gap between flags is also smaller.

Great and I’ll get the new code soon. Thanks Vinnie and Jules.

Now if we can get the hinting in there, we have a much improved font system and you don’t know how much time this will save me.

Does VFLib only work with embedded fonts and does it coexists with the Juce font system?

Well, like I said, VFLib has a solution:

vf::FreeTypeFaces

I don’t think hinting really belongs in JUCE, since it requires FreeType.

Hello Vincent,
I’m doing some tests with the FreeTypeFaces class of your VFLib. Everything works great except that the text is horizontally compressed as if I was using a condensed typeface.
The image shows the windows editor and a juce label using your FreeTypeFaces.
Both are using the font “Source Sans Pro - Regular”. I specified a point height of 11 (the same pointsize as in the windows editor) and changed the “drawFittedText” to “drawText” in my custom LookAndFeel, to avoid any horizontal distorsion.

[attachment=0]Freetypeface.png[/attachment]
As you can see, the output doesn’t match. Do you have any idea why the font looks like a condensed font when I’m using your Freetype approach?
Thanks.
Jan

Try turning off ClearType and compare the results. Other than that, I am unsure. Does this just happen with Source Sans Pro, or is it a problem with all fonts?

I’ve disabled ClearType and tried two other fonts but the result is the same. The text looks in some way condensed and the “withPointHeight” method returns a much smaller text as any Windows text editor tool with the same points.
Do you have tried to compare a juce label that is using your Freetype classes and the “withPointHeight” method to the output of a windows editor or MS Word?
Maybe it’s something in my code but this is a pretty simple test app and I don’t know where things could go wrong. I’ve tested this even with the standard Arial Windows font and still the same problem???
Any help appreciated.

Are you on the latest tip?

Pulled the master from github of juce and VFLib yesterday.

I think the first step is to make a 1 line change to the JUCE Demo application so that it uses withPointHeight in the Fonts and Text page instead of setHeight. Then, compare the output of JUCE Demo to system generated text and see if there’s a difference. If there is a difference, it means that Jules recent changes for calculating the point height coefficient on Windows still has a bug. If there is no difference then we need to dig deeper.