Re: Latin2 default font

[Marko Mikulicic]

Fred Kiefer wrote:


> I think that your problem is that you did not recreate the font cache
> after you changed your font path. (This has to be done manually by
> deleting the file  ~/GNUstep/Library/Fonts/Cache/0: where the display
> name may be different for your machine) This would explain why the
> fallback font fixed is used.


I did it, but I was joked by a bug in Xfree 4.0.3 witch crashed xfs and 
blocked font_cache leaving the cache unconsistent. I discovered that the
cause was the TrueType fontpath (or some font within).

After cleaning that up gnustep requested iso8559-8 !!! helvetica font 
(wich didn't have). I just needed a quick hack so I edited my fonts.dir
files to point from iso8559-8 to iso8559-2.


> As for the multibyte glyph drawing the problem is not to add the code in
> the XGFontInfo class (for this we would just store the encoding in an
> ivar and use the correct function in the drawing and string length
> method. What is missing is that the front-end hands on 8 bit strings to
> the back end code for drawing (This is now local to the
> NSStringDrawing.m file) so any 16 information is already lost before the
> NSFont object gets involved. I think it is possible to change this as a
> quick hack, but for a general solution we will have to generate glyphs
> that are suitable for the font and hand them on to the back end.
>
> I hope this helps and explains a bit of the background. If you are
> interested in taking over any part of the font improvement I am willing
> to share any advise I can provide.


Thanks a lot. Currently I'm very busy implementing porting a big 
database app from qt+postgres to gnustep+oracle (c++ drives me insane 
althrough qt is cute. EOF is incredible and surprisingly gstep-db works 
great (~)).
I have three weeks for that.
After that I will take some time and try hard to solve the america vs. 
resto-of-the-world character war, at least a next step.

Now I need a quick hack. I'm able to display latin2 text now but 
textfields simply don't want to accept the accented chars (to hex: e6 e9 
b9 be c8 f0 ae c6 d0 a9, char: éæ¾¹ðÈÆ®©Ð (mozilla maybe screws up)).
 As you see the latin1 "AE","(C)","(R)","\'E" and other valid latin1 
symbols are not accepted when I set xkb to sl (slovenian).
When I use swiss keymap the key for "\'e" (è) is displayed as "\vc", 
because they have the same value. I seems that it does no conversion for 
output but somehow filters/convert the input keystrokes based upon the 
current keymap (I thought X should do that).
(I tried with GSTest->Keyboard input test, and textfields).

Can you tell me where to look and hack to avoid this conversion. I'd 
like at least to fool it both at input & output that it's handling 
latin1 but with fonts remapped.

I have another question: The only gui feature I need besides fonts is 
the possibility to type longer strings than the width of the text field.
It appears that the editing field is convinced to be multiline and wraps 
  to a new line at word boundary, making word disappear.
Text should scroll left as cursor goes on.
Is that possible ? I have seen no API or information to set a textfield
mono- or multiline, so I understand it's difficult to him know what's 
the right behavior, event if it is implemented.
 I think this is the disadvantage to have one class implement all from 
multiline richtext scrollbarred editors with full-fledget wordprocessing 
features to a simple field editor.
 I cry for a Mac OSX or an OpenStep for intel CD, just to see what is 
the expected behavior, what's a bug, what's not gnustep fault :-(

However thanks a lot for the insight.

Marko

PS: for the accented chars above I used the TeX notation


> Fred
>
> PS: I read in another mail that you are a "Self" fan. How is that status
> of the Linux port of this language? I used to play around with Self
> myself, almost ten years ago now.


The port status is "antartic" :-)

The Cichon's linux port itself is almost done ... on sparcs :-)
The problem is that the intel has no register stack and the code
generation, exception handling, ... was written with that on mind.
The one who written that code should have no problems porting it to
intel (David Ungar ported it to PowerPC, but just the non-optimizing 
compiler. it's sloow). I prefered to reimplement it from scratch,
maybe missing all the nifty features of their implementation
(but R4 was a long project) but at least it was amusing.
If you are interested you can take a loop at http:/ww.openself.org.
It's not even in alpha state but parses and dynamically compiles exe 
code to i386 machine code (I started playing also with my alpha).
Several things missing ... I don't have the time and there are very few 
entusiast to help me :-(