archi
archi copied to clipboard
Rendered OSX label font sizes on diagrams differ from Windows/Linux
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.
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.
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...
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 ?
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.
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 ?
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.
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.
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.)
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
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.
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.
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.