Hi Carlos,
>Yes, it was the latest version. However, it needed some rework because
>of the latest changes.
>
>The patch is now in CVS. Testing is required in order to find and fix
>bugs before the release, so anyone willing to do some testing, please,
>get the CVS version and report the bugs found.
Great. Thanks for getting this in there.
The only issue I have found so far is if I open up the following
simple schematic:
v 20041228 1
T 30500 59000 9 14 1 0 0 0 2
line 1
line 2
I get the following warning:
o_text_set_info_font: character ! not found!!!
Okay, but why? I noticed in system-gafrc.in:
; The newline.sym symbol is not used!!. Use excl.sym or the newline
; will not be handled correctly!!.
Why isn't newline.sym being used and what causes this breakage?
Going back into my inbox archive, I found a previous message from you:
[snip]
> The bug which I was going crazy with has to do with the following code
> in o_text_load_font:
>
> case('\n'):
> temp_string = g_strdup_printf("%s%cnewline.sym",
> w_current->font_directory, PATH_SEPARATER_CHAR);
>
> case('!'):
> temp_string = g_strdup_printf("%s%cexcl.sym",
> w_current->font_directory, PATH_SEPARATER_CHAR);
> break;
>
> When converting the code to a hash table, I was matching the '\n'
> character with newline.sym, which was incorrect.
Why is this incorrect?
> The case of the '\n' character has no "break" instruction, so the '\n'
> matches the excl.sym... and there's a memory leak, since temp_string is
> allocated and filled with the path of newline.sym, and then allocated
> again and filled with the path of excl.sym .
> So now I wonder... what's doing newline.sym in the font directory?
The newline.sym file is a dummy font def file and should be
loaded when a newline character is found.
Thanks.
-Ales
