Hi Experts,

Using the newest svn update, on Suse Linux, I created a Lazarus project with just an empty Form1 and set a "Build Mode" "LCLWidgetType" to "CustomDrawn".

This does compile just fine, but when running it, I get:

Exception class 'RunError(201)'
in file ttload.pas, line 262.

What am I missing ?

Thanks,
-Michael

Hello,

Please open a bug report and there provide a full backtrack (You can get one going in the menu View->Debug Windows->Call stack)

And also add {$define CD_Debug_TTF} to the file
lcl/interfaces/customdrawn/customdrawndefines.inc and add there the log

Il 22/03/2012 19:16, Felipe Monteiro de Carvalho ha scritto:

If CD_Debug_TTF is enabled, a number of .txt files will be created in /tmp. Namely one file per font name, plus two files named lxfontpaths.txt and lxfontlist.txt.
Please report both the existence of those files, and the contents of the two lxfont...txt.
Thanks

Giuliano

Il 23/03/2012 09:23, Michael Schnell ha scritto:

This means that the crash occurs *before* those file are written. Which restricts the area, and helps reading the stack dump.

Thank you

Giuliano

Felipe Monteiro de Carvalho wrote

(You can get one going in the menu View->Debug Windows->Call stack)

Do you mean this:

#0 SYSTEM_$$_HANDLEERRORADDRFRAME$LONGINT$POINTER$POINTER at :0 #1 SYSTEM_$$_HANDLEERRORFRAME$LONGINT$POINTER at :0 #2 ?? at :0
#3 LOAD_TRUETYPE_DIRECTORY(0xb7ca0548, 0) at ttload.pas:262 #4 FACE_CREATE(0xb7ca0548, 0xbfffee90) at ttobjs.pas:1850 #5 CACHE_NEW({CLAZZ = 0x838cb10, ACTIVE = 0x0, IDLE = 0x0, IDLE_COUNT = 0}, 0x55555555, 0xbfffee90) at ttcache.pas:332
#6 TT_OPEN_FACE(0xb7c84aac '/usr/share/fonts/truetype//luxirb.ttf', {Z = 0x55555555}) at lazfreetype.pas:521
#7 FONTSSCANFORTTF(0xb7c843ac '/usr/share/fonts/truetype//', 0xb7fce1b0) at customdrawn/customdrawnproc.pas:852
#8 BACKENDLISTFONTPATHS(0xb7c6c020, 0xb7c841a0, 0xb7fce1b0) at customdrawn/customdrawnwinapi_x11.inc:691
#9 GENERICAPPINIT(0xb7c6c020) at customdrawn/customdrawnobject.inc:88 #10 APPINIT(0xb7c6c020, {PIXELSPERINCHX = 96, PIXELSPERINCHY = 96, COLORDEPTH = 24, INITIALIZED = true}) at
customdrawn/customdrawnobject_x11.inc:198
#11 INITIALIZE(0xb7c94280) at include/application.inc:450 #12 main at /tmp/project1.lpr:18

And also add {$define CD_Debug_TTF} to the file lcl/interfaces/customdrawn/customdrawndefines.inc and add there the log

Seemingly no files were created in /tmp.

Thanks,
-Michael

Hmmm.

I did the

{$define CD_Debug_TTF}

No file *lxfont* has been created in /tmp

There, I only see the files of (not yet stored) Lazarus project.

-Michael

Giuliano Colla wrote

This means that the crash occurs *before* those file are written. Which restricts the area, and helps reading the stack dump.

I seem to remember that when I tried Customdrawn some weeks ago, when compiling, I got a message that I am missing some font related library. Now I don't see such a message any more. This might be related.

-Michael

Il 23/03/2012 09:45, Michael Schnell ha scritto:

Could you please verify the contents of the directory /usr/share/fonts/truetype?

There's something really strange there, because the two slashes are understandable only if there's an empty string in between, which doesn't make much sense.

Thanks

Giuliano

As I don't know what to expect there, I can't verify the dir content. I just can do can ls -l

Let me know what more I can do.

drwxr-xr-x 2 root root 98304 Nov 18 14:05 100dpi
drwxr-xr-x 2 root root 86016 Nov 18 14:05 75dpi
drwxr-xr-x 2 root root 4096 Nov 18 13:56 cantarell drwxr-xr-x 2 root root 4096 Nov 18 14:05 cyrillic drwxr-xr-x 3 root root 4096 Nov 18 14:05 encodings drwxr-xr-x 2 root root 28672 Nov 18 14:05 misc
drwxr-xr-x 2 root root 4096 Nov 18 14:05 Speedo
drwxr-xr-x 2 root root 4096 Nov 18 14:52 truetype drwxr-xr-x 2 root root 4096 Nov 18 14:05 Type1
lrwxrwxrwx 1 root root 20 Nov 18 13:51 URW -> ../ghostscript/fonts drwxr-xr-x 2 root root 4096 Nov 18 13:47 util

Thanks
-Michael

Sorry, I forgot to paste the content of "truetype"

total 30044
-rw-r--r-- 1 root root 105468 Nov 12 1998 andalemo.ttf -rw-r--r-- 1 root root 286620 May 11 2000 arialbd.ttf -rw-r--r-- 1 root root 224692 May 11 2000 arialbi.ttf -rw-r--r-- 1 root root 206132 May 11 2000 ariali.ttf -rw-r--r-- 1 root root 275572 May 11 2000 arial.ttf -rw-r--r-- 1 root root 117028 Nov 10 1998 ariblk.ttf -rw-r--r-- 1 root root 111476 Nov 10 1998 comicbd.ttf -rw-r--r-- 1 root root 126364 Nov 10 1998 comic.ttf -rw-r--r-- 1 root root 311508 May 11 2000 courbd.ttf -rw-r--r-- 1 root root 234788 May 11 2000 courbi.ttf -rw-r--r-- 1 root root 244156 May 11 2000 couri.ttf -rw-r--r-- 1 root root 302688 May 11 2000 cour.ttf -rw-r--r-- 1 root root 611212 Oct 22 20:51 DejaVuSans-BoldOblique.ttf -rw-r--r-- 1 root root 672300 Oct 22 20:51 DejaVuSans-Bold.ttf -rw-r--r-- 1 root root 580168 Oct 22 20:51
DejaVuSansCondensed-BoldOblique.ttf
-rw-r--r-- 1 root root 631992 Oct 22 20:51 DejaVuSansCondensed-Bold.ttf -rw-r--r-- 1 root root 576004 Oct 22 20:51 DejaVuSansCondensed-Oblique.ttf -rw-r--r-- 1 root root 643852 Oct 22 20:51 DejaVuSansCondensed.ttf -rw-r--r-- 1 root root 345208 Oct 22 20:51 DejaVuSans-ExtraLight.ttf -rw-r--r-- 1 root root 235848 Oct 22 20:51 DejaVuSansMono-BoldOblique.ttf -rw-r--r-- 1 root root 313856 Oct 22 20:51 DejaVuSansMono-Bold.ttf -rw-r--r-- 1 root root 241972 Oct 22 20:51 DejaVuSansMono-Oblique.ttf -rw-r--r-- 1 root root 333636 Oct 22 20:51 DejaVuSansMono.ttf -rw-r--r-- 1 root root 611556 Oct 22 20:51 DejaVuSans-Oblique.ttf -rw-r--r-- 1 root root 720012 Oct 22 20:51 DejaVuSans.ttf -rw-r--r-- 1 root root 332036 Oct 22 20:51 DejaVuSerif-BoldItalic.ttf -rw-r--r-- 1 root root 341072 Oct 22 20:51 DejaVuSerif-Bold.ttf -rw-r--r-- 1 root root 331128 Oct 22 20:51
DejaVuSerifCondensed-BoldItalic.ttf
-rw-r--r-- 1 root root 316440 Oct 22 20:51 DejaVuSerifCondensed-Bold.ttf -rw-r--r-- 1 root root 338140 Oct 22 20:51 DejaVuSerifCondensed-Italic.ttf -rw-r--r-- 1 root root 330012 Oct 22 20:51 DejaVuSerifCondensed.ttf -rw-r--r-- 1 root root 338776 Oct 22 20:51 DejaVuSerif-Italic.ttf -rw-r--r-- 1 root root 363200 Oct 22 20:51 DejaVuSerif.ttf -rw-r--r-- 1 root root 35908 Oct 22 20:56 DroidSansArabic.ttf -rw-r--r-- 1 root root 191032 Oct 22 20:56 DroidSans-Bold.ttf -rw-r--r-- 1 root root 3640264 Oct 22 20:56 DroidSansFallback.ttf -rw-r--r-- 1 root root 23076 Oct 22 20:56 DroidSansHebrew.ttf -rw-r--r-- 1 root root 1173140 Oct 22 20:56 DroidSansJapanese.ttf -rw-r--r-- 1 root root 117072 Oct 22 20:56 DroidSansMono.ttf -rw-r--r-- 1 root root 36028 Oct 22 20:56 DroidSansThai.ttf -rw-r--r-- 1 root root 190044 Oct 22 20:56 DroidSans.ttf -rw-r--r-- 1 root root 189916 Oct 22 20:56 DroidSerif-BoldItalic.ttf -rw-r--r-- 1 root root 184836 Oct 22 20:56 DroidSerif-Bold.ttf -rw-r--r-- 1 root root 177176 Oct 22 20:56 DroidSerif-Italic.ttf -rw-r--r-- 1 root root 172532 Oct 22 20:56 DroidSerif-Regular.ttf -rw-r--r-- 1 root root 4012 Nov 18 14:52 encodings.dir -rw-r--r-- 1 root root 201610 Nov 18 14:52 fonts.dir -rw-r--r-- 1 root root 2 Jul 6 2010 fonts.dir.rpmorig -rw-r--r-- 1 root root 201610 Nov 18 14:52 fonts.scale -rw-r--r-- 1 root root 2 Jul 6 2010 fonts.scale.rpmorig -rw-r--r-- 1 root root 139584 Nov 10 1998 georgiab.ttf -rw-r--r-- 1 root root 156668 Nov 10 1998 georgiai.ttf -rw-r--r-- 1 root root 142964 Nov 10 1998 georgia.ttf -rw-r--r-- 1 root root 158796 Nov 10 1998 georgiaz.ttf -rw-r--r-- 1 root root 334284 Oct 22 23:25 GohaTibebZemen.otf -rw-r--r-- 1 root root 136076 Nov 10 1998 impact.ttf -rw-r--r-- 1 root root 118144 Nov 7 14:45 LiberationMono-BoldItalic.ttf -rw-r--r-- 1 root root 105308 Nov 7 14:45 LiberationMono-Bold.ttf -rw-r--r-- 1 root root 124064 Nov 7 14:45 LiberationMono-Italic.ttf -rw-r--r-- 1 root root 108020 Nov 7 14:45 LiberationMono-Regular.ttf -rw-r--r-- 1 root root 134444 Nov 7 14:45 LiberationSans-BoldItalic.ttf -rw-r--r-- 1 root root 136536 Nov 7 14:45 LiberationSans-Bold.ttf -rw-r--r-- 1 root root 161356 Nov 7 14:45 LiberationSans-Italic.ttf -rw-r--r-- 1 root root 127588 Nov 7 14:45
LiberationSansNarrow-BoldItalic.ttf
-rw-r--r-- 1 root root 109820 Nov 7 14:45 LiberationSansNarrow-Bold.ttf -rw-r--r-- 1 root root 131592 Nov 7 14:45 LiberationSansNarrow-Italic.ttf -rw-r--r-- 1 root root 112592 Nov 7 14:45 LiberationSansNarrow-Regular.ttf -rw-r--r-- 1 root root 138908 Nov 7 14:45 LiberationSans-Regular.ttf -rw-r--r-- 1 root root 150200 Nov 7 14:45 LiberationSerif-BoldItalic.ttf -rw-r--r-- 1 root root 146532 Nov 7 14:45 LiberationSerif-Bold.ttf -rw-r--r-- 1 root root 143816 Nov 7 14:45 LiberationSerif-Italic.ttf -rw-r--r-- 1 root root 151868 Nov 7 14:45 LiberationSerif-Regular.ttf -rw-r--r-- 1 root root 69872 Oct 22 23:25 luximbi.ttf -rw-r--r-- 1 root root 74076 Oct 22 23:25 luximb.ttf -rw-r--r-- 1 root root 69496 Oct 22 23:25 luximri.ttf -rw-r--r-- 1 root root 71784 Oct 22 23:25 luximr.ttf -rw-r--r-- 1 root root 85756 Oct 22 23:25 luxirbi.ttf -rw-r--r-- 1 root root 87160 Oct 22 23:25 luxirb.ttf -rw-r--r-- 1 root root 86396 Oct 22 23:25 luxirri.ttf -rw-r--r-- 1 root root 88732 Oct 22 23:25 luxirr.ttf -rw-r--r-- 1 root root 65568 Oct 22 23:25 luxisbi.ttf -rw-r--r-- 1 root root 69972 Oct 22 23:25 luxisb.ttf -rw-r--r-- 1 root root 66372 Oct 22 23:25 luxisri.ttf -rw-r--r-- 1 root root 67548 Oct 22 23:25 luxisr.ttf -rw-r--r-- 1 root root 280464 Oct 22 23:25 SyrCOMAdiabene.otf -rw-r--r-- 1 root root 106024 Oct 22 23:25 SyrCOMAntioch.otf -rw-r--r-- 1 root root 308212 Oct 22 23:25 SyrCOMBatnanBold.otf -rw-r--r-- 1 root root 289840 Oct 22 23:25 SyrCOMBatnan.otf -rw-r--r-- 1 root root 102104 Oct 22 23:25 SyrCOMCtesiphon.otf -rw-r--r-- 1 root root 79668 Oct 22 23:25 SyrCOMEdessa.otf -rw-r--r-- 1 root root 289584 Oct 22 23:25 SyrCOMJerusalemBold.otf -rw-r--r-- 1 root root 309024 Oct 22 23:25 SyrCOMJerusalemItalic.otf -rw-r--r-- 1 root root 294696 Oct 22 23:25 SyrCOMJerusalem.otf -rw-r--r-- 1 root root 702612 Oct 22 23:25 SyrCOMJerusalemOutline.otf -rw-r--r-- 1 root root 309916 Oct 22 23:25 SyrCOMKharput.otf -rw-r--r-- 1 root root 317316 Oct 22 23:25 SyrCOMMalankara.otf -rw-r--r-- 1 root root 289728 Oct 22 23:25 SyrCOMMardinBold.otf -rw-r--r-- 1 root root 290896 Oct 22 23:25 SyrCOMMardin.otf -rw-r--r-- 1 root root 103020 Oct 22 23:25 SyrCOMMidyat.otf -rw-r--r-- 1 root root 105408 Oct 22 23:25 SyrCOMNisibin.otf -rw-r--r-- 1 root root 642460 Oct 22 23:25 SyrCOMNisibinOutline.otf -rw-r--r-- 1 root root 104056 Oct 22 23:25 SyrCOMQenNeshrin.otf -rw-r--r-- 1 root root 102496 Oct 22 23:25 SyrCOMTalada.otf -rw-r--r-- 1 root root 153512 Oct 22 23:25 SyrCOMTurAbdin.otf -rw-r--r-- 1 root root 294304 Oct 22 23:25 SyrCOMUrhoyBold.otf -rw-r--r-- 1 root root 294288 Oct 22 23:25 SyrCOMUrhoy.otf -rw-r--r-- 1 root root 333900 May 11 2000 timesbd.ttf -rw-r--r-- 1 root root 238612 May 11 2000 timesbi.ttf -rw-r--r-- 1 root root 247092 May 11 2000 timesi.ttf -rw-r--r-- 1 root root 330412 May 11 2000 times.ttf -rw-r--r-- 1 root root 123828 Apr 9 2001 trebucbd.ttf -rw-r--r-- 1 root root 131188 Apr 9 2001 trebucbi.ttf -rw-r--r-- 1 root root 139288 Apr 9 2001 trebucit.ttf -rw-r--r-- 1 root root 126796 Apr 9 2001 trebuc.ttf -rw-r--r-- 1 root root 136032 Nov 12 1998 verdanab.ttf -rw-r--r-- 1 root root 154264 Nov 12 1998 verdanai.ttf -rw-r--r-- 1 root root 139640 Nov 12 1998 verdana.ttf -rw-r--r-- 1 root root 153324 Nov 12 1998 verdanaz.ttf -rw-r--r-- 1 root root 118752 Jul 10 1998 webdings.ttf

Hello,

Please try again with the latest Lazarus SVN, I changed it so that it should now create those log files in /tmp/ before the exception.

Please also send you file /etc/fonts/fonts.conf

These results are very wierd, could you attach the file itself? It is probably very small.

I reviewed FontsScanDir and I can't see how it would add a wrong directory since it makes a search in the directory and only adds non-empty directories o.O

I wonder if an extra DirectoryExists check would fix the issue. If it does it would be very wierd =D

Il 23/03/2012 11:07, Felipe Monteiro de Carvalho ha scritto:

lxfontlist.txt will be empty, because it's filled up after the exception, but lxfontpaths.txt should tell something.

Il 23/03/2012 11:23, Felipe Monteiro de Carvalho ha scritto:

What I suspect of are the results of XGetFontPath: I've taken it as gospel, but maybe it's a Devil's deed!
lxfontpaths.txt should tell something.

Felipe Monteiro de Carvalho wrote

Hello, Please try again with the latest Lazarus SVN, I changed it so that it should now create those log files in /tmp/ before the exception.

I get this in /tmp:

lxfontlist.txt is 0 Bytes.

lxfontpaths,txt:

/usr/share/fonts/Type1//
/usr/share/fonts/URW//
/usr/share/fonts/truetype//
/usr/share/fonts/encodings/large/
/usr/share/fonts/Type1/
/usr/share/fonts/util/
/usr/share/fonts/100dpi/
/usr/share/fonts/Speedo/
/usr/share/fonts/misc/
/usr/share/fonts/75dpi/
/usr/share/fonts/cyrillic/
/usr/share/fonts/URW/
/usr/share/fonts/cantarell/
/usr/share/fonts/truetype/

-Michael

Felipe Monteiro de Carvalho wrote

These results are very wierd, could you attach the file itself? It is probably very small.

OK
-Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fonts.conf
Type: text/xml
Size: 5320 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120323/05849d0b/attachment.xml>

Dolphin decided to open the file by Konqueror (Konqu-error ?) and same showed the stuff I copied :(

-Michael

Giuliano Colla wrote

What I suspect of are the results of XGetFontPath: I've taken it as gospel, but maybe it's a Devil's deed! lxfontpaths.txt should tell something.

Yes, we can see that the first dirs are the ones with // which points to XGetFontPath

The simplest solution is making a search and replace all occurences of // to / before adding to the list

Il 23/03/2012 11:47, Felipe Monteiro de Carvalho ha scritto:

I've verified that // doesn't affect TT_open_face (just by changing FontPath:=APath+Rslt.name into FontPath:=APath+PathDelim+Rslt.name, and thus having a double slash before all font names).

It originates from XGetFontPath, but it should be harmless.

Now I'm beginning to suspect the ttf file itself. What does TT_open_face attempting to open a corrupted ttf file?
As far as I can guess the file which gives rise to the error (luxirb.ttf) shouldn't be the very first file to be scanned.

Giuliano Colla wrote

Now I'm beginning to suspect the ttf file itself. What does TT_open_face attempting to open a corrupted ttf file?

LazFreeType crashes in some TTF files. I have no idea about the root cause, if the files are problematic or if those are simply bugs in LazFreeType. See:

http://mantis.freepascal.org/view.php?id=21456
http://mantis.freepascal.org/view.php?id=21519

My idea is assigning all of those bugs to circular as soon as we identify exactly which TTF files crash and make it part of the second LazFreeType bounty.

@Michale Schnell

Could you open a bug report and attach there you file /usr/share/fonts/truetype//luxirb.ttf

Il 23/03/2012 11:46, Michael Schnell ha scritto:

Just to understand where the problem is, you may download from this link:

http://www.copeca.it/colla/luxi.tar.bz2

my copy of Luxi ttf fonts (it comes from Fedora 5, because more recent Fedora have dropped it, and have replaced it with Liberation font).

If you want, you may check if they're identical to yours. If not you may put them in place of yours and see if something changes.

Giuliano

Giuliano Colla wrote

http://www.copeca.it/colla/luxi.tar.bz2

I replaced my truetype directory by this and restarted the system. In fact I see the "Luxi" fonts in the list in LibrOffice.

Retrying the test project: no change.

-Michael

Il 23/03/2012 15:46, Michael Schnell ha scritto:

A new stack dump might tell if we're always stuck with luxi fonts, or if there's another offending font.
Did you keep the old ones, and check if there's any difference (a diff should tell)?

Il 23/03/2012 15:53, Giuliano Colla ha scritto:

FYI. You don't need to restart the system, as far as Lazarus application is concerned: it scans the font directories each time you launch the program. Customdrawn, (unless explicitly requested to use native fonts, but this is still not yet implemented, at least in Linux) performs a custom writing: it paints the text in the object canvas, and gives to the X server a full image to display. Therefore it can use fonts X server is not aware of, provided they're in a reasonable search path. If you change a font, the new font is loaded when the program is started again.

In fact I found that renaming my truetype directory is not enough. The name seems not to matter but the locatrion. So I removed it and not my old Fonts have vanished in LibreOffice and I only see Luxi

in lxfontpaths.txtI see:

/usr/share/fonts/Type1//
/usr/share/fonts/URW//
/usr/share/fonts/encodings/large/
/usr/share/fonts/Type1/
/usr/share/fonts/luxi/
/usr/share/fonts/util/
/usr/share/fonts/100dpi/
/usr/share/fonts/Speedo/
/usr/share/fonts/misc/
/usr/share/fonts/75dpi/
/usr/share/fonts/cyrillic/
/usr/share/fonts/URW/
/usr/share/fonts/cantarell/

The call Stack ist:

#0 SYSTEM_$$_HANDLEERRORADDRFRAME$LONGINT$POINTER$POINTER at :0 #1 SYSTEM_$$_HANDLEERRORFRAME$LONGINT$POINTER at :0 #2 ?? at :0
#3 LOAD_TRUETYPE_DIRECTORY(0xb7ca0548, 0) at ttload.pas:262 #4 FACE_CREATE(0xb7ca0548, 0xbfffee84) at ttobjs.pas:1850 #5 CACHE_NEW({CLAZZ = 0x838dbf0, ACTIVE = 0x0, IDLE = 0x0, IDLE_COUNT = 0}, 0x55555555, 0xbfffee84) at ttcache.pas:332
#6 TT_OPEN_FACE(0xb7c84a6c '/usr/share/fonts/luxi/luxirb.ttf', {Z = 0x55555555}) at lazfreetype.pas:521
#7 FONTSSCANFORTTF(0xb7fbf0dc '/usr/share/fonts/luxi/', 0xb7fce1b0) at customdrawn/customdrawnproc.pas:852
#8 BACKENDLISTFONTPATHS(0xb7c6c020, 0xb7c841a0, 0xb7fce1b0) at customdrawn/customdrawnwinapi_x11.inc:698
#9 GENERICAPPINIT(0xb7c6c020) at customdrawn/customdrawnobject.inc:88 #10 APPINIT(0xb7c6c020, {PIXELSPERINCHX = 96, PIXELSPERINCHY = 96, COLORDEPTH = 24, INITIALIZED = true}) at
customdrawn/customdrawnobject_x11.inc:198
#11 INITIALIZE(0xb7c94280) at include/application.inc:449 #12 main at /tmp/project1.lpr:18

Hope this helps,
-Michael

Il 23/03/2012 16:04, Michael Schnell ha scritto:

What is apparent is that, in your specific environment, LazFreeType crashes when it tries to open luxirb.ttf, no matter where it's located, provided it's in one of our search paths. LazFreeType is used by the customdrawn project, but it's not part of it.

You may help in two ways:

1) By creating a bug report to fpc Lazarus bugtracker ( http://bugs.freepascal.org/ ) to the effect that ttload.pas crashes in your environment, when attempting to load luxirb.ttf, including a pair of your stack dumps, and the file luxirb.ttf. This will help fixing LazFreeType. Maybe someone will then ask more details, but it's up to them.

2) Test Customdrawn in your environment. This means that until the bug in LazFreeType isn't fixed, you must get rid of Luxi fonts. I believe you may survive without them ;-). Tho this effect you must:

* Get rid of the /luxi directory which you now have put in /usr/share/fonts, moving it to a place where nobody will look for it, sort of ~/Badfonts. (better keep it, so that you can move it back in place to verify that the bug has been fixed, if and when..)
* Put back in place your /truetype directory where it belongs, i.e. in /usr/share/fonts, but get rid of luxi fonts inside it, e.g. by deleting luxi*.ttf, or by renaming all luxi*.ttf to something like luxi*.ttf.disabled, or luxi*.bad

If there's no other font which LazFreeType doesn't like, you should be able to run your test program,
and also the example you'll find in:
/YourPathToLazarusSvn/lazarus/examples/androidlcl/nonandroidtest.lpi Not everything in it works as it should, but it's work in progress.

Giuliano

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120326/1d5c7ddd/attachment.html>

Ooops. I Installed Luxi because this has been requested by you, after I reported the problem. So the problem existed before I installed Luxi, here seemingly some other TTF font was in progress when the error emerged. Of course I will remove Luxi if you don't need it for having me do tests with same installed.

Of course I already reverted the system to the original state (i.e. the TTF that had been installed by the SUSE distribution in the /truetype dir. But seemingly LAZFont (and other TTF aware programs) don't care about the directory the ttf files are in, as long as it is a subdir of /usr/share/font

If there's no other font which LazFreeType doesn't like, you should be able to run your test program,

That is what I tried as a result of your requesting me to test with Luxi. I removes all other TTF fonts but the Luxis. So the result is:
- Crash with some TTFs but without Luxis
- Crash with no TTFs but the Luxis

So - as the Luxis seem to work for you - I conclude that the problem is not the internals of any TTF files.

Not everything in it works as it should, but it's work in progress.

Of course I do know this.

In fact I don't consider to _use_ Customdrawn, I am just trying to help, as I think it is a very interesting project, that I might want to use some day in the future.

(OK, In the Lazarus forum I learned that this qualifies me to be a troll. )

Thanks,
-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120326/ef402598/attachment.html>

Michael Schnell ha scritto:

Be aware that Luxi fonts DID exist among other fonts in your system, in the truetype font directory, since the beginning, and one of them was causing the crash, namely luxirb.ttf.
I sent you another copy, just to see if your fonts were somehow corrupted. You always get a crash when it tries to load luxirb.ttf, which is one of those damned Luxi fonts, no matter if it's the original copy coming from Suse installation, or a fresh copy sent by me. The crash occurs when it is executing LazFreeType package code. Why this happens with your Suse and not with my Fedora may be related to some error in LazFreeType, which shows with one version of system libraries, and not with another, but LazFreeType developers have better tools than us to investigate.

Giuliano

@Michale Schnell

Could you please open a bug report and attach there your file /usr/share/fonts/truetype//luxirb.ttf there?

You are right.

So I removed the luxis that were in the fonts/truetype dir

I kept the luxis that you sent in the /fonts/luxi dir.

LibrOffice still does see the Luxis. So it in fact is true that the dir the ttf files reside in does not matter.

Testing an empty project:

#0 fpc_raiseexception at :0
#1 SYSUTILS_$$_RUNERRORTOEXCEPT$LONGINT$POINTER$POINTER at :0 #2 SYSTEM_$$_HANDLEERRORADDRFRAME$LONGINT$POINTER$POINTER at :0 #3 ?? at :0
#4 LOAD_TRUETYPE_DIRECTORY(0xb7ca07d8, 0) at ttload.pas:262 #5 FACE_CREATE(0xb7ca07d8, 0xbfffee78) at ttobjs.pas:1850 #6 CACHE_NEW({CLAZZ = 0x838e030, ACTIVE = 0x0, IDLE = 0x0, IDLE_COUNT = 0}, 0x55555555, 0xbfffee78) at ttcache.pas:332
#7 TT_OPEN_FACE(0xb7fce2ac
'/usr/share/fonts/truetype//DejaVuSerifCondensed-Italic.ttf', {Z = 0x55555555}) at lazfreetype.pas:524
#8 FONTSSCANFORTTF(0xb7c843ac '/usr/share/fonts/truetype//', 0xb7fce1b0) at customdrawn/customdrawnproc.pas:856
#9 BACKENDLISTFONTPATHS(0xb7c6c020, 0xb7c841a0, 0xb7fce1b0) at customdrawn/customdrawnwinapi_x11.inc:696
#10 GENERICAPPINIT(0xb7c6c020) at customdrawn/customdrawnobject.inc:88 #11 APPINIT(0xb7c6c020, {PIXELSPERINCHX = 96, PIXELSPERINCHY = 96, COLORDEPTH = 24, INITIALIZED = true}) at
customdrawn/customdrawnobject_x11.inc:198
#12 INITIALIZE(0xb7c94280) at include/application.inc:449 #13 main at /tmp/project1.lpr:18

/usr/share/fonts/Type1//
/usr/share/fonts/URW//
/usr/share/fonts/truetype//
/usr/share/fonts/encodings/large/
/usr/share/fonts/Type1/
/usr/share/fonts/luxi/
/usr/share/fonts/util/
/usr/share/fonts/100dpi/
/usr/share/fonts/Speedo/
/usr/share/fonts/misc/
/usr/share/fonts/75dpi/
/usr/share/fonts/cyrillic/
/usr/share/fonts/URW/
/usr/share/fonts/cantarell/
/usr/share/fonts/truetype/

-Michael

Il 26/03/2012 17:16, Michael Schnell ha scritto:

No luck. Now it's the DejaVu font creating the problem. There's a bug in LazFreeType, connected with your environment. No way out except:

1) wait for CustomDrawn implement native drawing (i.e. not using LazFreeType)

2) wait for LazFreeType people to fix the bug.

Giuliano

Giuliano Colla wrote

No luck. Now it's the DejaVu font creating the problem. There's a bug in LazFreeType, connected with your environment. No way out except:

We can work around the issue until the real bug is fixed by filtering out fonts list with the filenames which give issues.

@Michael Schnell

Where is the bug report with the font files attached?

Please attach both
/usr/share/fonts/truetype//DejaVuSerifCondensed-Italic.ttf and /usr/share/fonts/truetype//luxirb.ttf

I am appalled that after 4 days and 2 tries you completely ignored my requests for a bug report. This completely undermines the bug fixing process.

Giuliano Colla wrote

No luck. Now it's the DejaVu font creating the problem. There's a bug in LazFreeType, connected with your environment. No way out except:

I supposed this.

No problem for me. I'm not in a hurry (the goal of running Lazarus programs on Android is just a private hobby).

I'll keep on trying to be helpful. Let me know if I can test something for you.

-Michael

Felipe Monteiro de Carvalho wrote

@Michael Schnell Where is the bug report with the font files attached?

I understand that the problem is not related to any dedicated font. So IMHO I should first reduce the count of TTF files to be analyzed (down to one ?) and hopefully find if there is a certain file that triggers the problem.

As you found that the luxib triggers the problem, and I found that as well the one I originally had as the one you sent do this, I, after having removed mine, now will remove yours as well and retest.

-Michael

Michael Schnell wrote

So IMHO I should first reduce the count of TTF files to be analyzed (down to one ?) and hopefully find if there is a certain file that triggers the

This is not as easy done as said.

I removed all "luxi*" files from the /usr/fonts dir and all it's subdirs.

But (even after a reboot) LibrOfficeWriter can use luxi fonts and the crash is the same as ever.

If you do suppose that some luxi file / luxi font triggers the problem, please let me know how to remove same.

-Michael

logs:

#0 SYSTEM_$$_HANDLEERRORADDRFRAME$LONGINT$POINTER$POINTER at :0 #1 SYSTEM_$$_HANDLEERRORFRAME$LONGINT$POINTER at :0 #2 ?? at :0
#3 LOAD_TRUETYPE_DIRECTORY(0xb7ca07d8, 0) at ttload.pas:262 #4 FACE_CREATE(0xb7ca07d8, 0xbfffee78) at ttobjs.pas:1850 #5 CACHE_NEW({CLAZZ = 0x838e030, ACTIVE = 0x0, IDLE = 0x0, IDLE_COUNT = 0}, 0x55555555, 0xbfffee78) at ttcache.pas:332
#6 TT_OPEN_FACE(0xb7fce2ac
'/usr/share/fonts/truetype//DejaVuSerifCondensed-Italic.ttf', {Z = 0x55555555}) at lazfreetype.pas:524
#7 FONTSSCANFORTTF(0xb7c843ac '/usr/share/fonts/truetype//', 0xb7fce1b0) at customdrawn/customdrawnproc.pas:856
#8 BACKENDLISTFONTPATHS(0xb7c6c020, 0xb7c841a0, 0xb7fce1b0) at customdrawn/customdrawnwinapi_x11.inc:696
#9 GENERICAPPINIT(0xb7c6c020) at customdrawn/customdrawnobject.inc:88 #10 APPINIT(0xb7c6c020, {PIXELSPERINCHX = 96, PIXELSPERINCHY = 96, COLORDEPTH = 24, INITIALIZED = true}) at
customdrawn/customdrawnobject_x11.inc:198
#11 INITIALIZE(0xb7c94280) at include/application.inc:449 #12 main at /tmp/project1.lpr:18

/usr/share/fonts/Type1//
/usr/share/fonts/URW//
/usr/share/fonts/truetype//
/usr/share/fonts/encodings/large/
/usr/share/fonts/Type1/
/usr/share/fonts/util/
/usr/share/fonts/100dpi/
/usr/share/fonts/Speedo/
/usr/share/fonts/misc/
/usr/share/fonts/75dpi/
/usr/share/fonts/cyrillic/
/usr/share/fonts/URW/
/usr/share/fonts/cantarell/
/usr/share/fonts/truetype/

Felipe Monteiro de Carvalho ha scritto:

The problem is that the same font files crash under Suse, and not under Fedora.

Giuliano

Giuliano Colla wrote

The problem is that the same font files crash under Suse, and not under Fedora.

Yes, but before I couldn't believe it, I thought that maybe the font was not being found in one case, but now I just tryed in Windows and the font worked for me =o

So now I suspect that he has maybe a 64-bits processor and the library has 64-bit issues ...

Or maybe because of the symbolic links that he has?

Now we have a bug report about this:

http://bugs.freepascal.org/view.php?id=21582

Il 27/03/2012 22:09, Felipe Monteiro de Carvalho ha scritto:

I had checked on that. It was crashing with the very Luxi fonts I sent to him, which I had tested both on an old Fedora 5 (to test compatibility with older Linux releases) and in Fedora 14, where I had installed it lifting it from Fedora 5. I could see that from the lxfontpaths before and after.

So now I suspect that he has maybe a 64-bits processor and the library has 64-bit issues ...

This might be the case.

Or maybe because of the symbolic links that he has?

No, in Fedora 14 all paths are symlinks. In lxfontlist I get duplicates of pretty much all fonts, because they're found both as symlinks, and in their real place, which is among the search paths we have:

Andale Mono=/etc/X11/fontpath.d/msttcore/andalemo.ttf Andale Mono=/usr/share/fonts/msttcore/andalemo.ttf Arial Black=/etc/X11/fontpath.d/msttcore/ariblk.ttf Arial Black=/usr/share/fonts/msttcore/ariblk.ttf
Arial Bold Italic=/etc/X11/fontpath.d/msttcore/arialbi.ttf Arial Bold Italic=/usr/share/fonts/msttcore/arialbi.ttf Arial Bold=/etc/X11/fontpath.d/msttcore/arialbd.ttf ........

All of the /etc/X11/fontpath.d/ are symlinks

Now we have a bug report about this: http://bugs.freepascal.org/view.php?id=21582

There's another font related issue, which I didn't mention, because I wanted investigate a bit more. It turned out that, in my platform, there are some fonts which simply won't display. If you select one of those fonts, no exception is raised, all appears to work fine, but there's no visible text in any widget. But magically, on Friday morning, between an svn update and the next, they did appear, and then disappear again. I'll try to collect more data on that matter. Abyssinica displays always fine. Are there CustomDrawn testers in Abyssinia?

Giuliano

Felipe Monteiro de Carvalho wrote

So now I suspect that he has maybe a 64-bits processor and the library has 64-bit issues ...

Nope. his is a 32 Bit System.

Or maybe because of the symbolic links that he has?

Maybe some library installed here (by the Suse Distribution or added by myself for some other purpose) is not compatible with the Lazarus Font recognition software. If you tell me which libraries are used I'll find out the versions.

At home I have an unmodified Suse 12.1 and an unmodified Suse 11.1 box.

I'll check whether it runs there.

-Michael

Giuliano Colla wrote

It was crashing with the very Luxi fonts I sent to him ...

I told you this (because I removed the other luxis from the /usr/share/fonts directory. But I am not sure any more, as after I removed *all* luxis from the /usr/share/fonts directory, LibrOffice Writer still is able to seemingly successfully change the font of a text to Luxi Mono, Luxi Sans and Luxi Serif.

-Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/customdrawn/attachments/20120328/c89d20d6/attachment-0001.html>

Michael Schnell ha scritto:

This will be interesting. I would like to perform a test on a Suse platform (I don't have any available at the moment), to compare the results, but I'll be unable to install one for a couple of weeks, because of many other things to do.

Giuliano

Giuliano Colla wrote

Il 27/03/2012 22:09, Felipe Monteiro de Carvalho ha scritto: > Or maybe because of the symbolic links that he has? > No, in Fedora 14 all paths are symlinks.

What about dead symlinks. Maybe those are not appropriately handled.

-Michael

Giuliano Colla wrote

..., because of many other things to do.

Why is this not unexpected to me ? :-)

Seemingly, nowadays, the western society is decided in two groups of adult people: those who suffer from their boring lives, and those who suffer from lack of time to do the things they would like to do.

Take a guess which group I belong to...>:o

-Michael

Giuliano Colla wrote

This will be interesting

I did these tests. Got the same crash, as well on Suse 11.4 as on an unmodified Suse 12.1.

I did take a look at the /tmp/lxfontpaths.txt and they are different (showing different dirs) but similar (including the double backslash phenomena)

Unfortunately I forgot to take them here. I'll send them tomorrow.

-Michael

Here you are

lxfontpaths.txt Suse 12.1 (unmodified):

/usr/share/fonts/Type1//
/usr/share/fonts/URW//
/usr/share/fonts/truetype//
/usr/share/fonts/URW/
/usr/share/fonts/cyrillic/
/usr/share/fonts/100dpi/
/usr/share/fonts/misc/
/usr/share/fonts/util/
/usr/share/fonts/truetype/
/usr/share/fonts/Type1/
/usr/share/fonts/encodings/large/
/usr/share/fonts/cantarell/
/usr/share/fonts/75dpi/
/usr/share/fonts/Speedo/

lxfontpaths.txt Suse 11.4:

/usr/share/fonts/Type1//
/usr/share/fonts/URW//
/usr/share/fonts/truetype//
/usr/share/fonts/truetype/
/usr/share/fonts/util/
/usr/share/fonts/encodings/large/
/usr/share/fonts/100dpi/
/usr/share/fonts/URW/
/usr/share/fonts/Type1/
/usr/share/fonts/Speedo/
/usr/share/fonts/cyrillic/
/usr/share/fonts/75dpi/
/usr/share/fonts/misc/

-Michael

Il 30/03/2012 10:52, Michael Schnell ha scritto:

Here you are lxfontpaths.txt Suse 12.1 (unmodified):

.....

Something we didn't consider. Which version of fpc are you using? (check with fpc -? ).

I'm using fpc 2.4.4 [2011/09/28], and not svn fpc, because I prefer using a stable compiler when testing new and possibly unstable widgesets.

I tried to corrupt a font file, just opening it in a text editor, and inserting a few characters at random, but still I get no errors.

Giuliano

Giuliano Colla wrote

Something we didn't consider. Which version of fpc are you using? (check with fpc -? ).

In the bug report he said he uses FPC 2.7.1 and this is my top suspect here. I never use 2.7.1, I always test with 2.6.0

Giuliano Colla wrote

Something we didn't consider. Which version of fpc are you using? (check with fpc -? ).

Free Pascal Compiler version 2.7.1 [2012/03/28] for i386

I did write this in Mantis.

Maybe I upgraded in between but this could be only a few days worth. Anyway, I re-tested with that version and got the same error.

-Michael

Michael Schnell wrote

Maybe I upgraded in between but this could be only a few days worth. Anyway, I re-tested with that version and got the same error.

Could you retest with FPC 2.6.0 ?

Sorry, but I don't know how I should do this without re-installing Lazarus on a clean machine.

If you can give me an easily workable advice I could give it a try (without any hope that it will change anything, as I can't imagine how a slightly different compiler would trigger a range check error.

I tried to localize the cause of the bug but unfortunately, at that lines, the source code is done using a lot of "with" definitions (which I never user for exactly that reason) and thus the debugger does not show the values of the variables in question.

I do have

"Free Pascal Compiler version 2.4.2 [2010/11/08] for i386"

do compile fpc and I always use the last recent svn version of FPC and Lazarus.

-Michael

Michael Schnell wrote

Sorry, but I don't know how I should do this without re-installing Lazarus on a clean machine.

A clean machine defeats the purpose of the test which is testing fpc 2.6 in exactly the same machine that you tested before, to be sure that fpc is the only thing that changed.

Suse uses rpms, so it is trivial to change your FPC:

rpm -e fpc
rpm -i fpc-2.6.0-0.laz.i686.rpm

You can download fpc 2.6.0 RPM from Lazarus source forge: http://sourceforge.net/projects/lazarus/files/Lazarus%20Linux%20i386%20RPM/Lazarus%200.9.30.4/

File: fpc-2.6.0-0.laz.i686.rpm

You must use Lazarus from SVN to test customdrawn, so I am confused about the term "install Lazarus" because Lazarus from SVN is not installable in Linux. You just download the source code and built it. Supposing you have Lazarus SVN you can do:

cd lazarus
make bigide

Then start lazarus and run the project.

Felipe Monteiro de Carvalho wrote

rpm -e fpc rpm -i fpc-2.6.0-0.laz.i686.rpm

That does look easy, but any time I installed an fpc version using some automated procedure, it did not work. Here I would need to first install the rpm version and after that return to the svn version, to stay up to date with testing new stuff. (One of the main issues has been finding and updating the fpc config file(s) used. )

So I really am not happy with killing the fpc installation running here.

I'd really rather try to find the reason of the Range Check Error in "TTLoad" line 262.

Maybe I can replace the the damn "with" notation by the actual variable names, to have the debugger show me the values.

-Michael

Michael Schnell wrote

Maybe I can replace the the damn "with" notation by the actual variable names, to have the debugger show me the values.

I did some test:

in TTload Line 261:

Loop with n = 0 runs fine

n= 1:
Tag is calculated to 1195656518
it crashes within GetULong when calculating "Checksum"

in GetUlong
frame_cursor is 20
current_frame shows lots of data
at position 20 I see:
162, 64, 158, 152, 0, 0, 1, 88, ...

It crashes when trying to leave the function GetULong,

Here the Disassembly Window shows that after returning from GetUlong, the code checks whether the result is negative (highest bit set) and initializes a Range Check error in this case.

This is correct, as Checksum is defined as a (signed) long.

So I suppose the problem is that Checksum in Fact should be defined as ULong. (Same supposedly is true for "Tag" as well).

So for a try I changed the code in TTLoad to call GetLong() instead. (acknowledging the supposedly erroneous fact that Checksum is signed)

This overcomes this problem, but now I get the range check error in line
498. when calling GetShort().

This code quite obviously is a bit buggy.

I suppose the working variant has been compiled with range check disabled.

I tried to disable range check in the project option, but I get the range check exception nonetheless.

Hope this helps,
-Michael

Il 02/04/2012 10:56, Michael Schnell ha scritto:

My solution is to have two different environments, and a few symlinks to select them.

I keep the stock installation from rpm's where they belong (/usr/lib/.. /usr/share/...)

I keep experimental things in my home directory: ~/Applications/lazarus, ~/Applications/fpc etc. This makes them writable, and I can play all tricks I want.

.lazarus in my home directory, is just a symlink to the appropriate directory: either .lazarus_9_30 or .lazarus_9_31
Then I have two different starter scripts, which adjust the symlink, and then invoke either stock startlazarus, or my copy's startlazarus. Each .lazarus_xx carries configuration information, and where fpc is located, so I can change things one side without endangering them on the other side.

Giuliano

Il 02/04/2012 11:31, Michael Schnell ha scritto:

I'm more and more convinced that this isn't a bug in TTLoad itself, but a problem with fpc versions. If something has been changed, as far as Longint, Long/ULong and Short/Ushort or related definitions are concerned (maybe because of x86_64 support or something like that), this would explain a lot.
GetLong and GetUlong also increments a pointer of the size of Long, or ULong. But if there's a mismatch between the actual size of a field in the ttf file, and the expected size of the variable, then you either get a wrong type, or increment of the wrong amount (so that next test fails). The problem is wether to fix TTLoad so that it works with fpc 2.7, or fix fpc 2.7 in order to make TTLoad work....

After introducing a {$R-} in

TTLoad.pas
LazFree.pas
TTMemory.pas and
TTObjs.pas

I in fact get a custom drawn Form.

:)

-Michael

Il 02/04/2012 16:32, Michael Schnell ha scritto:

Hooray!

Giuliano

Not really :-(

1) It's not a good omen if something only works when the debugging features are switched off. Obviously the source code needs some review.

2) I can show the naked Form. But hen I place a TButton or a TLabel on that form I get a range check exception, again. (Now in TTInterp line 482). I don't think it makes much sense to try to disable the range checking there, too.

I updated the Mantis accordingly.

-Michael