On Wed, Feb 08, 2006 at 09:14:37PM +0100, Davide Viti wrote: > > After testing, it seems that the "cut first character" is related to > > italic. Indeed, if you have a look at[0], you'll see that the same word > > is not rendered the same way when italic or not (see the first word - in > > RTL way, obviously - in the zoomed areas). When aleph (the vertical bar > > glyph) is italic, it goes out and is then cut. before I forget about the converstion on d-boot: <adn> zinosat: there must be a box for the text area <adn> and the italic version goes out of bounds <K_Dallas> adn, that is why in TeX there is an italic correction for each font <adn> zinosat: a solution can be to add a space at the beginning of this string <zinosat> adn, gtk_text_buffer_create_tag (description_buffer, "italic", "style", PANGO_STYLE_ITALIC, NULL); <adn> ok, either pango or the font is the one to blame here <adn> but I want to know whether the character is also cut with a space or not <zinosat> adn, you should just tell me which string needs the space <adn> #. Type: text <adn> #. Description <adn> #: ../hw-detect.templates:3 <adn> msgid "Detecting hardware, please wait..." I then created a version of hw-hardware containing the extra space in the appropriate string of ar.po and tried to roll up a mini.iso including this modified udeb and only nazli.ttf. Kamion's advice was not enought for me to rebuild the image: tomorrow I'll try again. Attilio: if it's not to much trouble a stupid application just showing that string on the gray area should be enough to reproduce the bug if that's a bug. maybe pasting the same string twice (once with the extra space, and one without it) would be even better. msgid "Detecting hardware, please wait..." msgstr " 箤ùêçïÌ ç®¤ñìçá 箤箦êøçñ..." In case the encoding gets messed up the string is at line 144 of: svn svn://svn.debian.org/svn/d-i/trunk/packages/hw-detect/debian/po/ar.po I owe you a pint of beer :) goodnight Davide
Attachment:
signature.asc
Description: Digital signature