I use QPainter::setRenderHint(QPainter::Antialiasing, true) to tell Qt that I want it to antialias any drawing I do (in this case, text drawn with drawText()).
This works fine and the text looks good, until I want to rotate the pixmap I'm drawing to e.g.
Painter.translate(0, height());
Painter.rotate(-90);
(to rotate the QPainter 90 degrees counterclockwise and bring it back into view)
The call to rotate() seems to disable antialiasing for any text drawn - the text is drawn at the correct rotation but without antialiasing. Other things seem unaffected - e.g. drawLine() still draws a nicely antialiased line.
Any idea what I'm doing wrong?
EDIT: Unsurprisingly, adding the text to a path and then filling that path gives me antialiased, rotatated text. I'd rather avoid this route if possible though.
EDIT (again): I've tried using QFont::setStyleStrategy(QFont::PreferAntialias) on the font I'm using, with no effect. However, some more experimentation shows that a basic font like Arial will still produce antialiased text when rotated, whereas my custom font (Swiss721 BlkCn BT for anyone who's interested) will not. Moreover, while this problem exists on Windows 7, I don't have the same issue when running on Ubuntu. This FAQ article would seem to suggest that Qt looks to the host OS to handle font antialiasing, so what kind of issues might Windows have in handling the rendering of this particular font (which is a TrueType, just like Arial)?
EDIT (last time, I promise): Upping the font size to 16pt or above kills the problem. It would seem that the issue is with rendering my particular font below 16pt - perhaps something to do with what was mentioned in the above blog article?:
On Windows 2000 fonts are usually not antialiased within a certain range (say sizes 8-16) to make text more crisp and readable.
I've actually had occasion to be in this part of the Qt code recently, and I think the behavior you are seeing is related to the following two bugs in Qt:
https://bugreports.qt.io/browse/QTBUG-21377
https://bugreports.qt.io/browse/QTBUG-20900
If I remember correctly (not 100%) sure, what you are actually seeing is the loss of the ClearType rendering on Windows. When there is a transformation applied, Qt gets the glyph pixels in a way that throws out the ClearType information, so things look more jagged.
If you wanted to look at the code yourself, the most likely place is /src/gui/text/qfontengine_win.cpp. You could also try turning off ClearType and see if they look similar.
One "guess" concerns your RenderHint. You use QPainter::Antialiasing here. Docu: "Indicates that the engine should antialias edges of primitives if possible." Primitives like lines, rects, etc. Try QPainter::TextAntialiasing instead.
Note: The RenderHints are flags, so you can bit-OR them if need be (and sounds like it is).
Related
Turns out I’m working with the Autodesk Forge viewer and Three.js, trying to render 2D text that can be interacted with (specifically select, rotate, and move).
To do this I am working with meshes (using MeshBasicMaterial, Mesh and TextGeometry) but it turns out that the text does not look perfectly sharp, it presents aliasing and I found that according to the API reference, the antialiasing is not applicable to 2d.
Here are some examples of the problem, as you can see, the more I move away from the plane, the worse the text looks (and even up close it doesn't look perfect):
I have tried to make a test representing the text with a Sprite (despite the fact that it would mean having to change the entire implementation already made with meshes of other functionalities) but apart from the fact that I cannot see it, I have seen example images and they do not appear either well: aliasing is visible from a distance and it looks really blurry up close. Here some examples:
Is there a way to correct this problem or is this the most I can get in 2D? I've tried searching for information on this but can't find anything helpful. And what has puzzled me the most has been realizing that antialiasing was not applicable in the case of 2d, like making it clear that nothing can be done to fix it.
I would be very grateful if you could solve my doubts, thank you very much in advance for your help.
An easier alternative, is to just use a higher pixel ratio for the renderer...
window.devicePixelRatio=2;
viewer.resize();
For example, using the custom geometry text, from Joao's demo, you can see the same aliasing issue at DPR=0.5 and DPR=1.0 ...
https://joaomartins-forge.github.io/textgeometry-sample/
But when I set the DPR=2.0, the text looks clean. The trade off is rendering performance, but your 2D drawings may be simple enough that it won't matter. You can use a 'mouse up' camera settle trick, to switch between DPR of 1 and 2, if you want a better UX experience.
There are a few ways to solve this aliasing issue for 2D (and 3D text).
The way I would recommend for your use case, is to use DIV elements (THREE.CSS3DRenderer), instead of text converted into three.js tessellated triangle geometry, as shown in this blog post:
https://forge.autodesk.com/blog/how-do-you-add-labels-forge-viewer
You can find out more information about THREE.CSS3DRenderer here:
https://threejs.org/docs/#examples/en/renderers/CSS3DRenderer
and an Example here: https://threejs.org/examples/#css3d_periodictable
Using CSS3DRenderer instead of CSS2DRenderer, means you will get the correct scaling (and rotation) of the div element as you zoom into your 2D drawing and the mathematics inside the calculation for the matrix transform has less edge-cases.
Once you are using DIV elements for your text, you will notice that the text is sharper and has no aliasing issues. That's because it is not being rasterized by the webGL pipeline, but by the SKIA library used by chrome/firefox/opera/etc for rasterizing text.
There is one final option, that uses signed-distance fields, but it's probably overkill for what you need.
Let me know if you want some example code.
I made a font. Some characters are intended to be combined (one glyph overlaid onto another, similar to प + े = पे).
This works fine when I import the font into a document editor, for instance, Libre Office. It also works fine when I type the script in a textarea in Google Chrome.
However, when the font is used in a textarea in Firefox, a tiny increment is made after each character, even though the horizontal advance is set to 0 in the TTF font file data.
This seems to be something built into Firefox, but it makes the combining look a bit off, and, if I wanted to overlay several characters on each other, it would look very bad. I think I read somewhere that Firefox knows to turn this off for certain fonts, but I cannot figure out how to do it. Or perhaps there's something in the CSS styling for the textarea? I'm at a loss.
Does CSS letter-spacing: 0; make it what it should be, or messing with that negative or positive get you anywhere?
Or check out the property font-kerning as well.
Is it normal that fonts I used to create site layout are pixelated? I use Georgia, and in photoshop I've smooth lines everything looks great. But when I tried to slice it up and code the css, Georgia font same size looks noticeably uglier!
What are your thoughts?
p.s. I use em to declare sizes in css.
That's because photoshop is using anti-alias technique on text.
Both OS and browser will impact the appearance of text in web page.For example, Mac OS has anti-alias text on all system UI. For windows, I believe they have an option called 'ClearType', once switched on all system UI will have smooth texts.
All fonts on the web will look a little pixellated unless you're on a Mac which renders type considerably better than PC.
The best way I have found to replicate how a font will look on the web is to set the Anitialiasing in Photoshop to 'sharp'.
It is conceivable that there will be CSS markup in the future that will allow antialiasing in the browser rather than OS based.
It is a common problem.
See this article
http://jontangerine.com/log/2007/10/smoothing-out-the-creases-in-web-fonts
The alternative is to use something like Cufon that generates images for your text. Best practice would be to only use it for headings.
http://cufon.shoqolate.com/generate/
I've found this too - each browser renders fonts differently. I often find fonts look much better in IE. Sometimes I opt to use images created in PS to get that smooth look, but for the most part I think people are used to how fonts are rendered in their browser of choice.
In photoshop, there's an option to "smooth" text.
See this image. Bottom right corner.
Remove this anti-alising to have a better view (but not exact) of how the font will look in browser.
I'm testing a new site, and I have a div with
background-color: #bbf6bb;
That seems innocuous enough to me. And yet, on my MacBook Pro, the color looks very different in Firefox 3.6 vs. Safari 4. In Safari, it's the color I'd expect from the hex value: a pale green. In Firefox, there's a definite bluish tint, making the color turquoise.
I'm aware of color inconsistencies that result from different treatment of images across browsers, but in pure CSS? Really? I'm guessing that Firefox trying to correct for my display in hopes of delivering better consistency with print, but I'd much rather have my site look the same hue to my users regardless of their choice of browser. Any ideas? Can someone confirm that Firefox is the culprit here?
[Update: This seems to have been a fluke. Specifically, it's a narrow issue with Firefox—see my answer below. I'm puzzled, but relieved.]
but I'd much rather have my site look the same hue to my users regardless of their choice of browser.
That's just the thing - without colour correction, it won't look the same to different users, because not every monitor has the exact same colour response.
I've isolated the issue! It's definitely a Firefox 3.6 bug (running on Mac OS 10.6). Seems to have something to do with having a large number of tabs open. If I create a new tab and go to the page, I get the slightly off colors (blue-green instead of just green). If I create a new window and go to the same page, the colors are accurate. And yes, this still occurs if I refresh both instances.
[Edit: Screenshot got misplaced, but I stand by this answer.]
color managent color profiles not only changes the images (that can save those) but also the rgb colors.
This has nothing to do with the browser, more with the user's monitor's colour correction. Every monitor has slight differences in how they show colours; additionally, the background lighting around the monitor plays a role, as well (warm daylight vs. usually colder inside lights etc. etc).
Sadly, there's nothing really you can do. You could embed a colour profile into your graphics, which is how design professionals do it when sending data to print, but that will provide halfway decent results only for the minuscule number of (graphic designers') monitors that has undergone colour calibration and is properly set up - and I think IE won't parse colour profiles at all.
I have a textarea where I measure the textWidth and textHeight to make sure the user cannot enter more text than can fit in the text area. I also extended the textArea with a textHeightNow and textWidthNow that measure the textField's dimensions since they update w/out requiring validation. Now this works great for 90% of the embedded fonts I'm using but any fonts that have giant serifs are not measured properly, for instance look at the 'f's in this text area:
alt text http://img.skitch.com/20091101-xhm5jguma1qgukg6fxrymrwr3u.jpg
You can see they get cut off on both sides because textWidth and textWidthNow both return an incorrect size not taking into account the massive serifs. The font size, coords and dimensions of the text area are all integers so thats not the problem, any other suggestions? I looked to see if textArea has a clipContent argument but it doesn't (that would have been nice).
Thanks
I've run into this problem before and as far as I can tell you have two options, none of them very nice:
Use the new flash.text.engine in
Flash Player 10... its very hard to use but
I think it will measure such fonts
(and ligatures) properly.
Draw the textfield into a bitmapdata
and use getColorBoundsRect to
determine its real dimensions.
I ended up using the latter as changing the whole app to the new engine would have been much much harder. You will need to tweak margins and use a larger textfield (inside some container) to be able to draw it properly, but it should work.