SliTaz Forum
You are not logged in.
Pages: 1
Dear all,
We have an application in hands, running on slitaz 4.
It happens to be (currently) targeted to french people, so messages' text has accents, "ç" and other special marks.
At first, I did nothing to have those texts properly rendered. They just appeared like they were expected to appear and voilà!
I have managed to make several small adjustments along the development way. One week ago, the texts did appear with the accents and other marks improperly rendered, but the system seemed to recover from that improper rendering with no conscious intervention.
This time, I did nothing to change from a proper text rendering system to an improper text rendering system, and the problem has survived all my attacks.
Any hint here? Anywhere to read about this question?
Thank you so much for being there!
Kind regards,
Offline
what kind of attacks? :-)
Offline
@ernia:
When the system has been performing well and it stops rendering those accents and other marks properly all of a sudden, you try to undo whatever you may have done recently, even if it doesn't seem to have a lot to do with the problem.
After having all those recent steps undone, I tried to recharge the fonts ([c]fc-cache -f -v[/c]), to copy the again into [c]/usr/share/fonts/truetype[/c] and fc-cache them again.
By means of fc-list, I checked all the fonts I was meant to use where available for system use.
No accents, however. There are accents in Spanish, you know. However, given that our target user was french, I changed SliTaz language definition to fr-FR; no accents shown.
SliTaz comes with DejaVu already in the system. I switched from the former font, no as stable as expected, supplied by our customer, to DejaVu and voilà! Accents, "ç" and all the glorious text rendering I was used to, even when using our customer font.
Thanks a lot for asking.
Any hint?
Offline
Pixman it responsible on rendering try find on this direction.
Offline
@gibor:
I googled it a bit and found that pixman is a part of the cairo graphics library.
Let me tell you what I am doing:
I must code on VisualStudio. All the graphic design is made there, along with most of the coding.
Once the requested feature is implemented in VS, which I do with Linux in mind, I go to Mono to check it all in Linux and against Mono.
I did no cairo development (direct development, at least). All graphics management is done inside Mono, as part of its runtime support for WinForms, I assume. I don't see why this support should change with no coding change on my side (at least, nothing related to text rendering).
In fact, I double test the Mono support in my PC, with XUbuntu 11.10, and in the target system, with SliTaz 4. The PC performs ok (both in WXP and in Linux)...
I appreciate your contribution, anyway. Thanks
Offline
hi arodulfo, knowing nothing about fonts but having seen some odd messages in Xorg.0.log, i started reading about the misteryous command you gave. this page
https://wiki.archlinux.org/index.php/Font_Configuration
has two rows into it that makes me think:
"Though Fontconfig is the standard in today's Linux, some applications still rely on the original method of font categorization: the Xorg server configuration"
"Keep in mind that Xorg does not search recursively through the /usr/share/fonts/ directory like Fontconfig does. To add a path, the full path must be used:"
slitaz's xorg does not know nothing about /usr/share/fonts/truetype, and you can see it with the suggested commands [c]grep /fonts /var/log/Xorg.0.log[/c] and [c]xset q[/c] (do tazpkg get-install xorg-xset before the command).
does your app get fonts from fontconfig or from xorg?
this could be the time to make /etc/X11/xorg.conf.d/20-Files.conf (maybe a little bit different name in 4.0) to point to the right FontPath and check the result with previous commands.
or maybe you need to instruct mono to use fontconfig?
Offline
Dear all,
First of all, I want to thank you all for your support.
Then, I have to say we have a little light on this subject.
Let's say we have a given app, developed in Visual Studio, hosted by SliTaz 4 and supported by mono.
I receive an application configuration xml which starts with a line like:
[c]<?xml version="1.0" encoding="utf-8"?>[/c]
Inside the configuration xml, there are Spanish terms with accents or symbols like our "ñ".
Our application does read those terms out of the configuration xml and tries to render them on screen.
No luck! The vowels are rendered with an empty space after them, and the "ñ", to say something, just disappears. If I use the DejaVu Sans truetype font, the accents, ñ and other marks are properly rendered, however, so I had an escape way at least.
Now comes the trick, and the small light: If I manually edit the configuration xml in SliTaz, with beaver for example, and change the original "ñ" with a new one, type Ctrl-S to save the file and run the application, voilà!, everything is rendered as it should.
I know I have something useful in hands, but lack the needed knowledge to tell what!
Any help?
@ernia:
You deserve some answer! I have been using FontConfig to register our fonts since the very beginning; mono and the application seemed to be quite comfortable with it, but I introduced some coding to the application so that it now looks for the proper font + style combination and decides what to do in case it is not installed or the installed font has no support for the style. In fact, the application reports when it finds the font as far as when it doesn't. Thanks!
Thank you so much for being there!
Kind regards!
Offline
arodulfo,
Now comes the trick, and the small light: If I manually edit the configuration xml in SliTaz, with beaver for example, and change the original "ñ" with a new one, type Ctrl-S to save the file and run the application, voilà!, everything is rendered as it should.
Do you tried just re-save file? Maybe make some not important changes like add extra space and delete it, then save. Is it work too?
If you use UTF-8 as encoding then there are two variants: to use or not to use BOM (Byte order mark). You can find two text files in the attachments. One of them uses BOM while other not use. Both files contains only one word: Español
How we can see the invisible?
We can use [c]hexdump[/c] command. How to check it? Download these two files in one folder, open terminal from this folder and command next:
[c]----------------------------------------
hexdump -C ./BOM.txt
00000000 ef bb bf 45 73 70 61 c3 b1 6f 6c 0a |...Espa..ol.|
0000000c
hexdump -C ./noBOM.txt
00000000 45 73 70 61 c3 b1 6f 6c 0a |Espa..ol.|
00000009
----------------------------------------[/c]
But two files contains the same text. Here BOM is three hidden bytes: "ef bb bf".
arodulfo, please check your xml file: before and after editing. Maybe, it "fails" with BOM and "wins" without BOM?
Offline
@Aleksej: Thanks a lot for your reply, and the help.
First of all, I also tried to just re-save the file, with no changes. It was of no use (no different result). In fact, receiving a proper config file (every symbol properly rendered), editing an unrelated field and saving the result used to end with the "offending" symbols not shown, even if they were shown at first.
We've made a couple of progresses as well.
If you receive the config xml file with the "offending" symbols and, instead of just removing and replacing them, you remove the complete syllable (Español >> Espa >> Español) and save the result, now the file seems to be properly read and its contents properly shown on screen, no matter if you then edit anything else and save the edited file: the contents keeps being properly shown.
On the other hand, if we generate the xml config file with utf-16 coding, all the fields are properly read and their contents properly rendered on screen. The problem is that there's no way to locally edit the config file to make small adjustments on the field. BEAVER, LEAFPAD and NANO seem to be unable to cope with such a file.
We must do some demonstrations to our customer. I can't promise I will be able to test your trick any soon. I will do it as soon as I have a little time to spare.
Anyhow, thank you so much for your hints.
Kind regards,
Offline
Pages: 1
[ Generated in 0.028 seconds, 7 queries executed - Memory usage: 1.56 MiB (Peak: 1.77 MiB) ]