Rendered OSX label font sizes on diagrams differ from Windows/Linux

[pschoepf]

Version of Archi

4.7.1

Operating System

OSX 10.15.5, Windows 10, Ubuntu Linux 20

Expected Behaviour

Rendering across platforms should be (mostly) similar especially in terms of layout

Actual Behaviour

Sorry for another rendering issue, I basically want to check if my observation is normal or may be it is just a local problem. I am running Archi on OSX (macbook pro retina or external 1080p display) and Windows 10 and I am suffering from portability of my diagrams due to very different font size rendering on my Mac and my Windows box. Basically the OSX fonts for labels (I am using Segoe UI regular 9 on both environments) in diagrams seem to be rendered much smaller than on windows and linux (checked on Ubuntu). Many of my diagrams created on OSX look awful on Windows because the labels do not fit into the bounding boxes of diagram objects.

Steps to Reproduce the Behaviour

I am attaching a screenshot showing same diagrams on three different platforms. Object sizes was 110x62 px, font used is Segoe regular in different sizes. As shown OSX font sizes seem to by size 2-3 smaller than the ones on Windows and Linux (I tried to highlight this with the red arrows in the picture).

What I would first like to check is if this is a "normal" issue due to the behaviour of the different platforms or something cause by my OSX config.

[Phillipus]

Yes, it's due to Mac having different DPI (72 not 96). The font information is saved with the font height in the model file but rendered differently on Mac.

Not sure how to work around this.

[jbsarrodie]

Not sure how to work around this.

I have to have a look at this. I thing we might have to define "Archi's DPI" and not rely on OS's DPI. I'll investigate...

[pschoepf]

Thanks for looking into it. I was playing a bit around with the code and it looks like there is already an adjustment for windows. Using the same for Mac resolves the issue for me. I just modified the respective code in AbstractDiagramModelObjectFigure and AbstractDiagramConnectionFigure and FontFactory.getAdjustedWindowsFont to do the adjustment also for Mac: (code snipped for AbstractDiagramModelObjectFigure)

public void setFont(Font f) { if(PlatformUtils.isWindows() || PlatformUtils.isMac()) { f = FontFactory.getAdjustedWindowsFont(f); } super.setFont(f); }

Wouldn't that be a proper workaround or would that have other side effects I do not see ?

[Phillipus]

It would mean that Mac users would now see all fonts larger compared with the same font in another app. "Lucida Grande 12" in Archi would look more like Lucida Grande 15 in another app.

[pschoepf]

I cannot speak for other users but I would definitely prefer this over portability issues with diagrams. Especially since eclipse anyway never feels like other native OSX apps. Furthermore, wouldn't the same apply already for windows users with custom font DPI settings ? If I get @jbsarrodie right this would also get into his direction of thought like having an Archi DPI over OS DPI. May be as a mitigation to the issue you mention it could be made configurable via a preference to give the user a choice ?

[Phillipus]

I disagree. If a user sets a font to Arial 12 the user expects to see Arial 12 on that system. If they now see a bigger font then they are not seeing Arial 12, they are seeing something like Arial 15. This would have huge impact on existing Mac models and would be an unwelcome surprise to Mac users! As a Mac user myself I would be confused, I would be saying "hang on, this isn't Arial 12!"

BTW - the same happens with other apps. If I have a MS Excel sheet using Arial 12 font it will appear smaller on Mac than on Windows.

BTW 2 - imagine the other way around setting all fonts to 72 DPI - all Windows users now start seeing smaller fonts. I think there would be some complaints.

[pschoepf]

Ok, I see you are at the other end of the preferences :-) I think it still would be great to have the choice to have better portability vs. native font size accuracy. It is currently very difficult to share diagrams in a team which uses a mix of OS platforms- (un)fortunately this is a "trend" in IT organisations. Especially now having new working models with more home office etc. in place. Regarding excel you are completely right, the only difference is that it also preserves the overall layout of the column ie. if a string on OSX fits into a column it also fits later on Windows.

[Phillipus]

I agree about portability but I don't think we should allow the user to set one font size but display a different font size, this would be confusing.

Apps that take the DPI into account are displaying the font at its proper size but seem to be adjusting the size of the UI objects to match (like Excel).

I don't know what the solution is.

(BTW - the Modelio modelling app also has the same problem.)

[Phillipus]

Thinking out loud...

• Store the font height as font height * system DPI
• When loading font height from model file, divide the height by system DPI

Example 1 :

• Windows user sets font to Arial 12. Font height is stored as 12 * 96 = 1152
• Windows user loads model. Font = 1152 / 96 = 12
• Mac user loads model. Font = 1152 / 72 = 16

Example 2 :

• Mac user sets font to Arial 12. Font height is stored as 12 * 72 = 864
• Mac user loads model. Font = 864 / 72 = 12
• Windows user loads model. Font = 864 / 96 = 9

[jbsarrodie]

Thinking out loud...

Same...

If a user sets a font to Arial 12 the user expects to see Arial 12 on that system

I tend to disagree. In fact font size only makes sense when printing a document because at the end it is based on physical paper size (1pt is 1/72 inch) and doesn't make sense anymore on modern OS because what we produce is shown on screen but DPI is not always related to the real physical size of the screen. Same font size on different applications on the same OS don't always look the same. I did lots of tests when we were working on the zoom issue and even on windows, Arial 12 doesn't have the same "screen" size on Word, Excel, Archi, Chrome...

The only important thing related to font is that they appear the same on the same application, whatever the OS. If I write a letter on Word under Windows, then I expect this letter to look the same on MacOS.

If they now see a bigger font [...]. This would have huge impact on existing Mac models and would be an unwelcome surprise to Mac users!

For me that's the only real issue, and this is about not being disruptive for existing models. But this doesn't mean we can't change anything.

I agree about portability but I don't think we should allow the user to set one font size but display a different font size, this would be confusing.

What is confusing is that the overall layout (text and figure) is not preserved: If I choose a specific font size for my text to fit without wordwrapping, I expect this to be the same on all OS.

I think that we should either set an arbitrary DPI for Archi itself (easy), or figure size should also be expressed in pt and zoomed according to OS DPI (not easy).

• Store the font height as font height * system DPI
• When loading font height from model file, divide the height by system DPI

I think that's a good solution, maybe the best. This would allow people to "see" font size like they are used to on other applications (even if this doesn't really make sense), and keep the overall diagram layout consistent across OS.

We just need to be careful and make sure that people working on the same model with different versions of Archi still see the same thing, or else "migrating" the model would be a one way operation.

[Phillipus]

We just need to be careful and make sure that people working on the same model with different versions of Archi still see the same thing, or else "migrating" the model would be a one way operation.

There would be migration and backwards-compatible issues for sure.

Possible:

• Save a Feature as <feature name="dpi" value="72"> for the object when the font is set by the user
• If present do the calculation

The next time we have an Archi UI sprint we might consider this.

[jbsarrodie]

I'm investigating a bit more on these font rendering discrepancies between OS.

FWIW, On my MacBook Pro running Ventura, most applications tend to render fonts the same way, but there's one exception: Outlook. Outlook tend to show the font bigger and it even seems to me the scaling factor is 96/72 (ie based on the DPI of Windows and MacOS). More than that: funny things happen if I copy some text from some app (e.g. TextEdit) and paste it into Outlook: the size on the screen stays the same, but the font size is changed to make this happen (e.g. what's set as 16pt in TextEdit becomes 12ps in Outlook). Reverse is true too (copying from Outlook and pasting in TextEdit keep the visual size but the font point number is increased).

So one can conclude that Outlook uses its own DPI settings which is 72, shows text using this setting, and does the conversion depending on the OS it runs on when copying/pasting to/from other apps.

[isalew]

I hit this when handing off of a diagram that used a custom font. It was modeled on a mac, but when moving to windows, font sizing was way off. It makes the diagram unusable without a jarchi script to reduce the font sizing by 20-30%.

Mac OS - Font Size 13

Windows OS - Font Size 13

[Phillipus]

I think I might have a solution. At least what I've implemented works...

When a user sets a font in Archi, Eclipse SWT creates a FontData string which is different for each platform:

Mac - 1|Times New Roman|13.0|0|COCOA|1|TimesNewRomanPSMT
Windows - 1|Times New Roman|10.125|0|WINDOWS|1|-27|0|0|0|400|0|0|0|0|3|2|1|18|Times New Roman
Linux - 1|Sans|12.0|0|GTK|1|

So there is a platform name in the string - |COCOA|, |WINDOWS| or |GTK| and from this we know on what platform the user set the font.

So all we have to do when rendering the font is look for this platform name and...

• If we are on Mac and the string contains |WINDOWS| or |GTK| then scale the font height by 96 / 72
• If we are on Windows or Linux and the string contains |COCOA| then scale the font height by 72 / 96

And we can display the new font height in the Font Chooser widget in Properties. For example, if we are on Windows and the font has been created on Mac with a height of 13 then we see 10 in the font chooser which is the effective height. Conversely, if we are on Mac and the font has been created on Windows with a height of 10 then we see 13 in the font chooser.

I think I will implement this for Archi 5.4 beta with an option to turn it off in Preferences.

[Phillipus]

Here's some screenshots of before and after using the same model on Windows and Mac

Present state

Windows:

Mac:

With the new fix

Windows:

Mac:

[sonear]

I will gladly test this on windows/Mac as soon as it is available. I have some views that I constructed to verify the font size test cases.

One test I have is to export the view as image to compare the resulting image size (in pixels) across platforms. If this works, I would expect those to be much closer than they are today.

Do you see similar exported images sizes with your test? Vs before?

Looks very promising.

Scott Griffith

[Phillipus]

Do you see similar exported images sizes with your test? Vs before?

The screenshots above are exported images.

[sonear]

Thx. I downloaded each image above and the EXIF dimensions are all the same before and after between platforms. I don't have same results. my Mac vs win result in different image geometry in current version

[Phillipus]

Thx. I downloaded each image above and the EXIF dimensions are all the same before and after between platforms. I don't have same results. my Mac vs win result in different image geometry in current version

The exported image size has nothing to do with the font height (this issue) or the platform. The image size depends on the host's display scaling. Mac is typically 2x scale because it has a retina display and so images will be exported at 2x scale. The image size on Windows will depend on the monitor device settings, if you have a regular monitor the image will export at 1x scale. There is an option in Archi's Preferences under "General -> Other -> Export images at double scale" to turn this on or off.

[Phillipus]

The workaround/fix/adjustment is now in Archi 5.4.0 beta 7. See https://forum.archimatetool.com/index.php?topic=1541.msg7969#msg7969

[sonear]

I did some 5.4 beta 7 interop testing of visual quality between Mac/Windows. My test case and observations are included in this image and in the attached model. It is worth noting that I started with the 4 notes in upper left as my baseline. Test case on it's own view to test exporting. Then passed it back and forth between mac -> win -> mac -> win... and so on while recording results.

I also included my basic model below for others to observe and record their findings.

Conclusion:

• when an element specifically has a specified font (different than the Archi default display font for views), the beta7 code works well in resizing the fonts within the element. When using the defaults (and the defaults are aligned between mac/windows... Say Verdana 12, this solution does not seem to scale the font as thought. This take us back to the original observation of font/size on platform 1 does not equal font/size on platform 2 due to DPI differences.

• I also made some observations about image export dimensions and resolution. I had assumed that "export images at double scale" would double their effective resolution but it seems to only change their dimensions and the original data is scaled up causing pixelization. Not sure if that is the intent. Am I interpreting this correctly?

Thanks for considering my results here and hope it helps validate your assumptions.

My concern about this approach is... If we set a standard internally that headings are Arial 24 and body text is Arial 12, then the scaling function will result in fonts settings that don't meet our standard. I am guessing others would see this and potentially change the elments to the standard on a different platform (which would be wasted effort as it would just be adjusted again on the other platform). So.. I could live with it but it would take some explaining internally.

thanks for all your efforts here.

Archi - 5.4 Beta 7 Test Results.archimate.zip

[Phillipus]

Thanks for the feedback.

when an element specifically has a specified font (different than the Archi default display font for views), the beta7 code works well in resizing the fonts within the element.

That's the only case where this new feature works. See https://github.com/archimatetool/archi/issues/655#issuecomment-2286508281

When using the defaults (and the defaults are aligned between mac/windows... Say Verdana 12, this solution does not seem to scale the font as thought.

That's right, because we're back to the original problem. Internally the font is not stored and so the font that is used is the one you set. In this case nothing is stored in the model file to say what the font is or on what platform it was set. When the model is loaded it uses that font without any adjustment, Ideally you'd set the default to be different on each platform to compensate. That's why the default font on Windows is "Segoe UI 9" and on Mac is "Lucida Grande 12".

I also made some observations about image export dimensions and resolution....

If you are using a hi-dpi monitor (2x retina for example) images need to exported with the double scaling set on as the monitor is used to render on.

My concern about this approach is...

The root issue here is that diagrams use pixels while fonts use points. This is a problem inherent in the Eclipse frameworks used and can be seen on other tools that use these frameworks (Modelio, Sirius, etc).

[Phillipus]

There is actually a "solution" to this problem and we discussed it in earlier comments in this thread - set the de facto DPI to 96 and adjust font size on all cases based on that. So the formula is:

If platform DPI != 96 then multiply font height by 96/DPI

(In fact we already do this on Windows when scaling is set to 125%, 150% or 175% and the DPI is not 96 but 120, 144, 168.)

The fonts will look the same size on all platforms and the only impact would be on Mac. A caveat is the comment I made earlier:

It would mean that Mac users would now see all fonts larger compared with the same font in another app. "Lucida Grande 12" in Archi would look more like Lucida Grande 15 in another app.

And the biggest issue is backward compatibility for Mac users as fonts would now appear bigger so you'd have to set the default font to something like Lucida Grande 9 instead of 12 and probably adjust existing font sizes to be smaller.

In fact you can try this now:

1. If you are using Archi 5.4. beta 7 make sure to turn off the new setting "Adjust font height for each platform", otherwise use Archi 5.3.
2. On the Mac ensure Archi is not running and edit the file Archi.app/Contents/Eclipse/Archi.ini (right click on the Archi app to "Show Package Contents" to get to this file)
3. Add this line to the end of the Archi.ini file and save it: -Dcom.archimatetool.adjustFontSize=true
4. Launch Archi

And:

1. Set the default font on Windows and Mac versions to the same, say Arial 10.
2. Create a model on Windows and set fonts for objects as required
3. Open the same model on Mac and compare font sizes

As I said, the big issue is managing backward compatibility for existing models on Mac, because all fonts will now appear bigger.

[sonear]

I'll do some testing on the above approach and see if this works for us.

Pixels vs points. This whole topic seems like a chapter right out of Flatland by Edwin Abbott.

Thanks for your detailed response.

[Phillipus]

Having spent more time experimenting with font scaling I've come to the conclusion that the implementation in Archi 5.4 beta 7 is not the ideal solution for the reasons mentioned in this comment and because of other issues.

I think what works is what was already proposed in this comment (and what some users are already using by setting the property -Dcom.archimatetool.adjustFontSize=true)

I have a build of Archi 5.4 that adds a new preference on Mac - "Scale fonts on Mac". This is effectively the same as the com.archimatetool.adjustFontSize property but exposed in Archi's Preferences. The default is "off". If set to "on" then fonts are scaled on Mac as we do already on Windows if the display scaling and DPI is not 96. Also, if this is set to on the default View font on Mac is "Lucida Grande 9" instead of "Lucida Grande 12" to compensate (the user will have to manually click the "Default" button in Preferences, Appearance, Fonts, Diagram Objects and Connections, or set their own preferred default font.)

If this is implemented the main problem is backward compatibility on existing models. By making the default preference "off" font scaling on Mac is opt-in, but it doesn't solve the problem of how to handle Views that have been created on Mac with the old font scaling.

[Phillipus]

The new implementation is now in Archi 5.4.