[openbeos] Re: StyledEdit issues : text encodings,opentracker integration, etc.

  • From: "shatty" <shatty@xxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Wed, 06 Nov 2002 22:48:25 -0800

Delay font sensitivity : I agree

Eventually integrate open tracker : I agree as well

Do the same as R5 for styled edit encodings :
Well, ok perhaps, but the question is which yucky
implementation of encodings do you want then?  :-)
Also I am not talking about localizing the interface
for the app.  This is just a question of how to handle
text encodings.  This issue comes up in three apps in
R5: StyledEdit, BeMail, and NetPositive.  We aren't
tackling NetPositive so it's out, although any browser
has the same issue.

BeMail, even from MDR, has 17 options so it seems that
it uses the conversion method.  (It does not support 
the japanese encoding either.)  My browsing of it also
shows that it never calls the BFont::SetEncoding which
confirms that suspicion.

StyledEdit from R5 supports only the encodings that
are supported from BFont so I suspect they used that
approach in that situation.  IMHO the BFont approach
is less worse than than the conversion approach but
the coverage is abysmal! (no east asian language 
support at all)

I'm prepared to implement the BFont approach with the
understanding that at some later point coverage will
be expanded.  But I would like some assurances from
our font people that it's a reasonable assumption.

I am especially worried since my cursory examination
of the freetype library yielded *no* occurances of 
"8859" in the code.  R5 supports font display for all
ISO-8859 standards from 1 to 10. (and MacRoman too)

My understanding of this is that we will have to
implement a wrapper around freetype that converts from
these encodings to the format that freetype accepts.
(UTF-8? UTF-16?)  If this is in the works for the
previously supported standards perhaps I need not
worry since it will presumably be possible at that
point to add support for more encodings.

I could see a possible future where we decide that
BFont::SetEncoding will not be supported due to the
constraints of our font engine.  In that case I'll 
have to wander back over to the conversion method
in the end anyway.  So... anybody care to play 
prognosticator?

Andrew

Other related posts:

  1. Home
  2. haiku
  3. Archive
  4. 11-2002