So my QT5 applications (OK, that's only OpenSCAD) now have a huge font. So huge actually that I can only read three words on the screen (“File”, “Edit”, “Editor” for the OpenSCAD menus). (I don't know which change caused that: I did not open it for some time).
I tried installing qt5ct to reset fonts to a sensible default value... except that this tool uses itself qt5 (that's logical, if a bit unsafe) and so is also unreadable.
Which configuration file should I try editing to make the thing usable again?
Info that might be useful: the machine is Debian testing; I don't know the exact QT version info since qt5ct does not recognize the --version switch.
Edit to add: although fonts are huge, icons are normal size, so this is probably not a screen resolution problem, but really a font problem.
Related
I am using Netbeans 8.2 and finding it generally great... however, when coding CSS font-family there is a very limited code completion list (sans-serif, serif, etc.). I have to fully type Arial, Helvetica, sans-serif;. Am I missing something? I have only the HTML5/PHP install.
If using Visual Studio Code the code completion for font-family is working.
Thanks in advance for any light you can shed on this.
Am I missing something?
No. I have a full install of NetBeans and get the same result as you.
If using Visual Studio Code the code completion for font-family is
working.
Well that depends on what you mean by "is working"...
A font-family name can be a family-name or a generic-family.
The generic-family names are formally defined ("serif", "sans-serif", "cursive", "fantasy", "monospace"), and those are provided as options in NetBeans with code completion:
However, family-name is defined as "the name of a font family of choice", meaning you pick a font that you want your web page(s) to use. Given that there are thousands of available fonts, NetBeans cannot know what specific fonts to provide during code completion for font-family. It has no idea what operating system or browser your application is going to use (and you may not either). And even if NetBeans did know the target environment, it would still not be able to provide a guaranteed list of safe fonts during code completion.
Of course some fonts are more popular than others so I suppose you could raise a bug report with NetBeans suggesting that they offer some additional font names on code completion based on popularity, but the process would be very subjective, and different people would would come up with a different lists.
I also checked what Eclipse and Intellij IDEA do for code completion for font-family. Eclipse is the same as NetBeans, offering only the generic-family names, but Itellij IDEA offers a huge list of fonts:
I am running on Windows 10 and it looks like Intellij IDEA is loading up all the names it finds in C:\Windows\Fonts. Perhaps that is what you would like NetBeans to do as well, but be mindful that selecting fonts from that list will not mean that the font will necessarily be available when your application runs in a browser of the user's choice on Android or macOS or iOS or Linux or some different version of Windows.
My own view is that NetBeans and Eclipse are doing the right thing, forcing you to think about what family-name(s) you want to specify, but others may feel differently.
My application allows the user to switch languages on the fly. I'm seeing that about 10% of the time the user switches to Chinese or Japanese, the glyphs for the UI text are being rendered improperly.
This application is running under Linux on an iMX6 platform. Qt 5.5.0 is being used. QML is used to render the UI. The corrupt text is being rendered using a QML Text control.
Example of corrupt font rendering
The font being used in question is Source Hans Sans Regular. I have tried loading this using a QML FontLoader and by loading it on the C++ side into the application font database (both methods exhibited the problem). I've tried using the (admittedly very strongly related) Noto fonts; same problem.
I have never seen corruption of text rendering when using Roboto for non-CJK text and, as mentioned, this works more often than not for CJK/Source Hans Sans.
The corruption is interesting because it looks like it is at the rendered bitmap level, not the glyph definition level (notice how some glyphs have the lower half correct, but the top half is corrupt).
Corruption does sometimes progress. This leads me to think the glyph bitmap cache memory is being overwritten further (just a theory as I'm not sure how Qt does font rendering). I thought it might be the QML garbage collection doing something odd, but loading the font on the C++ side didn't make a difference.
I'm going to try using 'native rendering' for the QML Text controls next.
Has anyone seen this before? Can anyone confirm FreeType is used for font management/rendering under Qt 5.5.0? Are there ways to influence how that font bitmap cache is managed?
Thanks!
Update: using 'renderType: Text.NativeRendering' did not eliminate the problem (although the corruption manifested slightly differently). And, given the limitations of that mode, just ended up with generally poorly rendered text (soft, poor scaling, etc - as documented).
Update 2: I built Qt with (as far as I know) all of the glyph caches disabled -- shouldDrawCachedGlyphs() returns false in my local build for the four instances of that call I was able to find -- but still encountered glyph corruption.
Update 3: Tried switching to use the software (non-OpenGL) Qt Quick 2 renderer by setting QMLSCENE_DEVICE=softwarecontext per docs; glyph corruption still occurred.
In this particular case, there is a bug in the OpenGL driver on the platform I'm working with. It affects FBO readbacks. Setting QML_USE_GLYPHCACHE_WORKAROUND=1 in the environment forces Qt to keep an additional copy of the glyph cache in RAM (since it cannot be read back from the graphics hardware when new glyphs are added).
The implication of this is that while rendering will be correct (since we're using a second cache which isn't corrupt) performance will be degraded slightly since there is an extra copy on the CPU and the glyph cache will use twice as much memory. Rendering quality is unaffected.
Qt support was able to point me in the right direction and qualify the implications associated with QML_USE_GLYPHCACHE_WORKAROUND.
I've been trying to get custom font rendering working in a Symbian Qt app (4.6) for some time. For most fonts and most glyphs, it all works just fine using a method similar to this.
However, for the majority of fonts many glyphs are rendered incorrectly - essentially, the wrong glyph is rendered. I've tried a Symbian C++ app using the same loading method, and that does render correctly. So, this does seem like a Qt bug, and in fact all the gory details are here.
Can anyone suggest a workaround to get full TTF font rendering working on Symbian^3 devices in Qt 4.6?
Although I have no experience with Symbian Qt Apps, I was working last year for several months in a dual environment Qt application (Win32 & Mac OS X) which has to do mainly with font rendering.
QFont rendering -in Win32/Mac OS X- in general runs smoothly, but if you have advanced font rendering requirements you may encounter several and severe problems:
a) It's not possible to find if a specific unicode character is really present in a specific font (i.e. it's not possible to totally disable the character-substitution mechanism - you can only provide substitution hints)
b) If you try to load some specific (bad?) TTF/OTF fonts for exclusive use of your application (i.e. to load not-installed fonts to use them in you application) the application crashes and the crash is inside the Qt Libraries code (it's trying to double-free some buffers).
This is a very rare bug to encounter: It was happened to me for just 5-10 fonts out of 90.000 fonts I tested, but it's still annoying if the main task of your application has to do with font-rendering.
My workaround was to use the FreeType2 (open source) library:
-> It never crashes (it just returns an error on bad fonts)
-> It's about 4-5 times faster than QFont rendering
FreeType2 is not a direct replacement for QFont and it for sure requires to spend some extra time to understand some basic (low-level) concepts before using it, but if you really need a fast and reliable library to render any TTF/OTF (+other) font into a gray or bw image, I highly recommend it as the ultimate choice.
The ultimate answer is that this is a QT bug, but happily it is fixed in QT 4.7.2. Now, just have to wait until the Ovi Store accepts Nokia QT 4.7.2 apps....
I have some buttons on a tabwidget. These buttons need to have some icon on top of them.
I am aware of QPixmap that will allow me to put an image on top of a button, but I see that these constructors take a filepath as a parameter. I want to avoid dragging icons around in a file after I build. I would like to embed these icons in the executeable somehow, so as to reduce the baggage that I need to lug around in order to make it work.
How can I accomplish this?
I am interested in hearing ways to accomplish my goal of not needing to drag icon files around with the executable; please focus on this aspect if you are confused about some terminology I may have used, as I am still learning Qt.
Of course you can embed icons, images and all other custom resources into your application.
Please read The Qt 4's Resource System (or click here for Qt 5)
You will have a resource file named something like ProjectName.qrc and these list the icons (usually PNGs). With Qt Creator it already starts out with a blank QRC file for you. When specifying the "file" you use the syntax in the manner of ":/Images/MyCrazyIcon.png" and the icon is loaded from the resource that is embedded into your executable. Note that Qt does not manage resources in the very most perfect way, which is to have them loadable upon demand but not always hogging up system memory; they ALWAYS hog up system memory, which really is not such a big deal if they are small. For the big graphics you want flushed out later, just specify a real file name (e.g., "MyBigFile.png" instead of ":/MyBigFile.png", which the latter points to a resource within the executable).
With the resource syntax the power is in the colon character ":", so you could even have ":MyFile.png", providing the QRC file is located in the same directory as the resources. That is how I am doing it, and so far see no downside of this syntax. I hate including ".../Images/..." in the syntax, so my resource names are addressed with ":MyPic.png" without the longer ":/Images/MyPic.png" and all works fine.
The Qt documentation states that AT THIS TIME they do not support true resource handling that Windows and Mac supports, but that things could change in the future. Remember, "true resource support" refers to that nice thing where you can place multi-megabyte graphics and sounds within your executable and never worry about them loading into memory until the magic time you request them. The QRC resources are loaded into memory when the executable is loaded up. The skinning by loadable file support more than makes up for this weakness. Qt is improving rapidly and one day they could very well support both the Windows and Mac resource systems. I am getting redundant and must go. Ta ta. Everybody mod me up, I need the points.
Maybe you should try this:
add a single line to your .pro project file:
RC_ICONS = myappico.ico
More Information: Setting the Application Icon
I have a requirement to be able to provide a flex component in English and several asian languages. I have looked at the flex documentation and it seems that I have to build several swf's, which feels wrong.
Does anyone know of a straightforward and practical way of bundling string resources in different languages and handling the fonts?
I guess you know the basics of how to localize a Flex application, but if you would like to know more there's a good and thorough description here: Runtime Localization.
In Flex 3 you have three options on how to solve your problem:
compile all languages into the SWF and switch language at runtime
compile a separate SWF for each language
compile no, or a default, language into the SWF and load additional languages at runtime
The first option is probably the most common, the least complex and doesn't have many drawbacks. The other two can be used if you have special needs, like having to keep down the size of the SWF at all cost, or need to load all strings from a database at runtime.
To implement the first option you create a resource bundle for each language (basically a number of .properties files that lives in a directory named after the locale, for example en_US for US English or sv_SE for Swedish). In the code you refer to strings by calling the resource manager:
<Label text="{resourceManager.getString('mybundle', 'mystring")'}/>
That will retrieve a string called "mystring" in the resource bundle compiled from "mybundle.properties" in the current locale.
To make sure each locale is actually compiled into the application you add -locale=en_US,sv_SE to the compiler flags (but change the en_US,sv_SE part to the languages you have resource bundles for). You also need to add the location of the directories to the source path: -source-path+=locale/{locale} (the "{locale}" part will automatically be replaced by the values of the -locale flag).
Now you have compiled all your languages into the SWF and can change languages at runtime. The way to do that is to modify the localeChain property of the resource manager:
resourceManager.localeChain = ["sv_SE", "en_US"];
With the settings shown above the resource manager will first look in the Swedish resource bundle, and secondly in the one for US English. You can set another order at any time, and doing so will change all texts in the application then and there.
I encourage you to read the description I referred to above, it explains this in greater detail, and most likely in a more understandable way. It also explains how to do some preparations you need to do before you can compile applications with locales other than en_US.
The other problem you have is with fonts. That one is trickier. The best thing would be to have a font that had the full Unicode range of characters, that way you would only need to embed that and any text could be displayed. However, that means that your options are a bit more limited. I know that there is at least one version of Aria in Windows that has an enourmous number of characters, and on the Mac there is a Helvetica (I think, or it might be Lucida Grande, or both) that also has most of the ones you need to display many asian languages.
Embedding all languages into the same SWF usually does very little to increase the file size, because text is very lightweight, but fonts are definitely not. Embedding a the whole Unicode version of Arial can increase the file size of a SWF by several megabyte, which kind of sucks for web applications. Depending on the situation you may have to compile one SWF per language, just because the font data would otherwise make the SWF unwieldy.
Beware of fonts. System fonts aren't the prettiest but Asian fonts are too large to embed. We resorted to embedding Latin fonts for English and switching to system fonts for Chinese.
Be careful about rotating system fonts - your text will disappear. I think Flash 10 might have fixed this.
Also, be very careful with the font string you specify for Chinese.
Most OSes have nifty fall-back logic - if you specify Trebuchet and try to render a Chinese character, your OS might decide to use some Asian font instead. Flash seems to mess up this fall-back logic and switch between two or more Asian fonts dynamically. We had cases where mousing over a text block would switch the font.
To fix this, specify a font which includes all the characters you need (without falling back to some other font). You will need to test this across OSes, etc.
We use Flex for the client part of our application and support I18N via ResourceBundles.
In Flex 2.01 the language has to be built into the SWF - you can't change it at runtime. In Flex 3 you can switch language at runtime.
http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:_Runtime_Localization
An important step left out above is to run the command:
copylocale.exe en_US sv_SE
from the bin folder of the sdk. This is in the article though.