I am developing a text editor application based on QTextEdit/QGraphicsTextItem and noticed that the results of QTextEdit on Windows are different to the ones on Mac.
Specifically, when testing with a multi line text snippet in the "Text Edit" sample of Qt 4.8.5:
When using large font sizes (48pt) the text layout is pretty much identical
When using small font sizes (8pt) the text snippet has a noticeably larger height on Windows
I've found a couple of related StackOverflow questions but didn't find a suitable answer in them. Thus I tried to dig deeper and figured out the following:
Font size 48pt: the line height on Mac and Windows are very close to each other (both about 60%)
Font size 8pt: the line height on Mac is about 50%. On Windows it is about 75%
When referring to "line height" I compared the ascent height (i.e. height of "T") against the height between them (between two text lines).
Here is a screenshot showing the problem. The red lines are the base lines of the Mac text lines.:
It seems that the line height causes the text layout to be different on Mac and Windows. Is there any way in Qt to enforce an identical text layout on Mac and Windows (Microsoft Word manages to do so)? Or does anybody have other suggestions about this?
If I'm not mistaken, Qt 4.8 in Mac uses system rendering engine & Windows and other platform uses Harfbuzz. Qt 5.X uses Qt Harfbuzz for all platforms. Two different rendering engine not likely to have same rendering out put. Try with Qt 5.2 if you can.
Related
Environment: Mac OS El Capitan; MBP 2012-Mid 15'.
Same problem on both built-in LCD and external LCDs. I have tried with 3 external monitors. Also same problem on another MBP with Retina internal LCD. Also, same problem occurs no matter the resolution is scaled, not scaled, or HiDPI.
As the screenshot shows, same font name + same font size + same text + same screen has different visual width in different text editors. I have tried to tune one of the font size to be like 14.1/13.9/etc, but not works, the text is either too small/narrow or too big/wide; what's more, some editors cannot use fraction font size.
Q1: How to show exactly same visual size for same font size?
Q2: Looks like there are two font rendering engines in the OS? If yes, how to specify which one to use for specified app or for all apps?
Thanks a lot.
I noticed that Sublime Text has much better rendering for some fonts and sizes than Scintilla based editors. How is that achieved? Is there some famous text renderer underneath it or they developed their own?
Sublime Text uses highly tuned settings over platform-specific libraries to render text. It has actually used several different libraries throughout the years. I couldn't find any specifics for OSX, but there are some details for Windows/Linux in the forums and release notes.
In ST3 build 3034, it is noted that the graphics rendering engine was "ported to Skia from Cairo". However, it is not clear if there was custom text rendering being done, or if it is just for UI elements.
Sublime Text 1
I can't find a good reference for version 1, but through bits and pieces of forum conversations, it looks like it may have been a custom rendering engine written on top of OpenGL. Other forum posts point out that all future rendering would be pure software as there was a lot of cross-platform issues caused by GPU rendering.
The best quote I could find was this:
Sublime Text 2 uses software rendering only. Ultimately, it caused too many compatibility issues in 1.x, and with going cross platform for version 2, that would only have increased. Nonetheless, I'll talk about Sublime Text 1.x for a bit.
The basic text rendering itself was fairly standard: textured quads are drawn to the screen, one per character. However, there are a few details worth noting:
* Characters are buffered, and sorted by color, to reduce state changes.
* Most OpenGL applications will have a single channel texture for the characters, and blend the desired color on top. Sublime Text uses RGB textures, with the text pre-composed with the correct foreground and background color. This takes more memory, but allows ClearType to be used, which is important for a text editor.
Sublime Text 2 (release notes)
Windows uses GDI, with an option added in build 2081 to use DirectWrite instead.
In build 2170, Pango was added as the rendering on Linux to improve support for cjk text.
Sublime Text 3 (release notes)
DirectWrite replaced GDI as the default renderer on Windows in build 3127, unless you are using the fonts Consolas or Courier New. GDI was kept as a rendering option in the settings.
For some time now, I've been working on a series of GUIs. I use a Mac running OSX to write all of my code, and the problem I've encountered is that it there are deviations in appearance when the GUIs are used in windows, some of which are minor, and some of which are very significant.
1) The text in the windows version is substantially larger overall. This results in some of my button titles simply going off the button, or panel titles moving beyond the panel.
2) Axes appear to be different dimensions between Mac and Windows. i.e. An axis that appears square on my Mac will appear elongated or rectangular on windows, and vice versa.
3) Graphical displays are different. This is the real problem. Some of my GUIs use axes to display text and model chemical reaction animations. On the Mac, they look perfectly fine, but on the windows system, the sizing is completely off.
I've set all "Units" to "characters" as suggested by the Mathworks help page, and I do not specify any fonts to allow each system to use its default. I have however, specified font sizes, but apparently, 12 point font on windows appears very different from 12 point font on mac.
Are there any ways around these problems? I thought setting a specified font size and allowing for use of default fonts would fix this, but it hasn't, and I'm a little dry for ideas at this point.
Try working in 'pixels' or absolute size units instead of 'characters', and apply a scaling factor to your font sizes.
Setting 'Units' to 'characters' is probably the wrong way to go for portability, and could be the main cause of your display sizing issues. Which specific Matlab page recommended that you do so? Was it talking about cross-platform portability? The characters unit is very convenient to work with, but it is tied to the font metrics for the default system font. (See the doco for Units property at http://www.mathworks.com/help/matlab/ref/axes_props.html). That's going to differ between different operating systems. Working with 'pixels' or inches/centimeters/points, which are absolute, will probably give you more uniform results across operating systems.
And you're not wrong: OS X tends to display fonts of a given size on screen smaller than Windows does. (Generally; YMMV depending on your display DPI and system settings and other things.) For example, I run my terminals and text editors at 10 or 12 points in Windows, but 14 point or larger on Mac. So apply a scaling factor to the font sizes you set in your GUI. Figure out what looks good on Mac, and then scale it in your code to something like windows_font_size = floor(mac_font_size * 0.8) and see how it goes.
If you want to be more precise in scaling, you could grab the ScreenPixelsPerInch and ScreenSize root properties with get(0,...). You may also be able to call down in to Java code to get precise font metrics info to help with font scaling choices.
Either way, you're going to have to test your code on both systems instead of just expecting it to work portably. If you don't have ready access to a Windows development system, consider setting up a Windows VM on your Mac. With file sharing between the two sides, you'll be able to try your code out on both platforms right as you work with it.
I encountered this problem as well.
Calling this function within the FUNCTIONNAME_OpeningFcn might alleviate your issues:
function decreaseFontSizesIfReq(handles)
% make all fonts smaller on a non-mac-osx computer
persistent fontSizeDecreased
fontSizeDecreased = [];
if ~ismac()
% No MAC OSX detected; decrease font sizes
if isempty(fontSizeDecreased)
for afield = fieldnames(handles)'
afield = afield{1}; %#ok<FXSET>
try %#ok<TRYNC>
set(handles.(afield),'FontSize',get(handles.(afield),'FontSize')*0.75); % decrease font size
end
end
fontSizeDecreased=1; % do not perform this step again.
end
end
We have standard flex 3 project, and We have left everything as default, no change in style at all, and we deployed our project and noticed that on Mac the character spacing is very bad and overall look and feel is not as clear as that of windows.
Here is the difference, left one is Windows and right one is Mac.. the default flex font chosen by Adobe is "Verdana", the left one looks pretty, but right one looks as its width and character spacing, everything is incorrect. I assume verdana font may not be available on Mac, but in that case I supposed adobe should have given default standard font of good quality.
alt text http://akashkava.com/images/MacFlashFontProblem.png
What can we do to resolve this? Will embedding Verdana font in flex project style will help?
Mac OS X and Windows have different text rendering engines. I've heard it said that Mac OS X tries to preserve the character shape while Windows tries to align with screen pixels at small sizes.
That's going to result in differences between how fonts are rendered, and there's really no way to work around it.
Personally, I think the example on the right looks much nicer; the one on the left looks square, like it's being rendered at too small a size, while the one on the right looks more like the font is supposed to look.
It's not a solution, but Verdana is available on every OS X box. See this Apple doc for 10.5; I couldn't find one on 10.6 but there is one.
The font used in xterms is extremely compact yet readable. What font is that? The closest I've found that I can use in other other applications is DejaVu Sans Mono or Bitstream Vera Sans Mono. Those are as compact as xterms vertically but take up more space horizontally.
I'd really like to switch from xterms to Terminal.app and this is the one thing holding me back.
(I also think that font would be much better for emacs, xcode, or whatever editor.)
ADDED: In Terminal.app you can adjust the character and line spacing for any font. Is this possible in other applications?
I'm open to any other font that is as compact and readable as the xterm font. Dina looks really nice but it doesn't seem to work for Mac.
I have successfully gotten Emacs.App to use the beloved misc-fixed 7x14 font. And it looks GOOD.
1) download ucs-fonts.tar.gz from http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
2) extract the file 7x14.bdf
3) install FontForge (fontforge.sourceforge.net)
4) open 7x14.bdf in fontforge
5) in fontforge do File->Generate Fonts with "No Outline Font" and "Apple bitmap only sfont (dfont)"
6) save as /Library/Fonts/FixedMedium7x14.dfont
7) in your .emacs (setq default-font "-apple-Fixed-medium-normal-normal--14----m-0-iso10646-1")
8) WIN
I've really taken a liking to Inconsolata:
http://www.levien.com/type/myfonts/inconsolata.html
But it's not really appropriate for an xterm. Better as a programming font.
I'd strongly suggest Monaco 9pt, not anti-aliased:
Never seen anything as readable and space-efficient. Note that it's the same number of pixels wide as Monaco 10, but slightly shorter.
It's not exactly the same, but 10 point Monaco (with anti-aliasing turned off) is pretty darn close. I'd say it's actually a little better, because Monaco's 1/l and O/0 glyphs are more distinct than the X font's.
Here are alternatives I've tried. (Thanks to Will and others.)
Monaco 10pt with .9 line spacing (I don't know how to squish line or character spacing in anything other than Terminal.app) takes up exactly as much vertical and horizontal space as the xterm font. Without the line space squishing it takes up more vertical space. I don't think the squishing harms readability. Monaco has the advantage of slashed zeros but has worse angle brackets (they bump into adjacent characters awkardly, eg, "~>"). Upper case characters ("A" in particular) also don't look as good in Monaco. Mostly though, they are about the same.
Monaco 9pt fixes the angle brackets and is more vertically compact than the xterm font (same horizontally). Capital I is pretty sucky (hard to distinguish from l and i and |).
ProggyTiny from Proggy Fonts at 11pt. Setting the line spacing to .9 makes it vertically slightly more compact than X11's xterm font. Either way, it takes up exactly as much space horizontally. With or without line space squishing though, I find this option definitively worse than Monaco. The other Proggy varieties seem to not be as compact as the xterm font.
Anonymous at 10pt with .95 character spacing (I still don't know how to squish character or line spacing in anything but Terminal.app) and normal line spacing is exactly the same size as the X11 font. Squishing the character spacing causes upper case characters to touch each other very slightly and numbers are rather ugly that way. With vertical (line) space squishing it can be made more vertically compact than the xterm font without harming readability.
(Anonymous at 9pt is very very compact and still quite readable.) I really don't like the caret ("^") in this font, with or without squishing.
FixedMedium6x13 set to size 13 and line spacing 0.80 yields the xterm font exactly. My friend David Yang reports that this works flawlessly for him on Snow Leopard. I'm on Leopard and it's unusable for me (with squished line spacing that makes it as compact as X11) because there's some kind of refresh problem -- it cuts off the tops of the letters until the terminal window re-renders, like when you alt-tab away from it.
Others I intend to try:
Envy Code R: http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-coding-font-released
Inconsolata: http://www.levien.com/type/myfonts/inconsolata.html
Droid Sans Mono: http://en.wikipedia.org/wiki/Droid_(font)
Just use one of these:
http://henrik.synth.no/fonts/6x12.dfont
http://henrik.synth.no/fonts/6x13.dfont
http://henrik.synth.no/fonts/7x13.dfont
http://henrik.synth.no/fonts/7x14.dfont
You might want to adjust the line height to 0.85 when you select the font.
(Thanks to Marty Vona for the guide)
The font used in xterms is extremely
compact yet readable. What font is
that?
The font you are referring to is known as "fixed" or "6x13".
I started (but gave up) a "6x13 redux" which was meant to be one of those TrueType fonts that only looks good at one size but was usable in Terminal.app. I gave up because creating a font with UNICODE glyphs is a HUGE undertaking. Just look at this glyph table for 6x13. BTW, that "6x13 Redux" font I created only seems to work in Terminal.app on Tiger, not on Leopard.
The closest I've come to 6x13 is ProggySquare at 11pt.
My favorite pixel font is 'Dina ttf 10px' at 16pt on a dark background. It makes a great font for coding, since it has slashed zeros, and distinct characters.
You can find the Mac TrueType version at http://www.geenat.com/?p=66
and the original bitmap version at http://www.donationcoder.com/Software/Jibz/Dina/index.html
The Proggy font that Dina is based on is also really sharp at a small text size. Unfortunately, it is a little too small for me.
Additionally, you can use SIMBL plugins to tweak Terminal.app to better suit you. In addition to the color preferences, I find all the plugins below really helpful when using Terminal.
For a start the default colours in Terminal.app are difficult to see. To fix this, you can install Ciaran Walsh's custom color plugin.
SIMBL - http://www.culater.net/software/SIMBL/SIMBL.php
Custom colors - http://ciaranwal.sh/2007/11/01/customising-colours-in-leopard-terminal
Tab Switching (if you prefer CMD-1 instead of CMD-SHIFT-{}/arrow keys) - http://ciaranwal.sh/2007/12/10/tab-switching-in-terminal
Visor - http://visor.binaryage.com/
MegaZoomer for Fullscreen - http://ianhenderson.org/megazoomer.html
The IR_Black color scheme - http://blog.infinitered.com/entries/show/6
X11 default fonts are usually bitmap fonts, which aren't of any use to non-X applications ... on my Mac box, the default font for X11 apps seems to be -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1, corresponding to the file /usr/X11/lib/X11/fonts/misc/7x14-ISO8859-1.pcf.gz
You can display the character table with the command /usr/X11R6/bin/xfd -fn -misc-fixed-medium-r-normal--14-130-75-75-c-70-iso8859-1 and check if it's the one you see in your xterms. If so, I'm afraid there's nothing to do: PCF fonts are (very) low resolution bitmap fonts, and that's why they look so good on screen, by the way (they just fit with your particular screen resolution); but they're no way other Mac OS X applications are going to use them.
I've been using Bitstream Vera Mono later DeJaVu Sans Mono (for more unicode characters) for quite a long time but I've switched a few months ago to the font used by Android, Google's OS for mobile phones, called Droid Sans Mono. It is really more readable for me. For Terminal.app, I do shrink it a bit horizontally though.
I've created the DinaPro font which is like the original Dina, but for Mac ... http://www.hexagonstar.com/blog/news/dinapro-coding-font-for-mac-released/
Try andale mono without anti-aliasing... it looks good on my mac pro 15in