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

  • From: "Rob Tijssen" <rob.tijssen@xxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>
  • Date: Thu, 7 Nov 2002 19:33:02 +0100

Isn´t it possible to let ALL the text encoding be done by one single
class/application/kit wich support add-ons (or is this already the
situation?), it looks that all apps are doing it by themselves and thats not
o/BeOS like :D

cheers, Rob

----- Original Message -----
From: "shatty" <shatty@xxxxxxxxxxxxx>
To: <openbeos@xxxxxxxxxxxxx>
Sent: Thursday, November 07, 2002 7:48 AM
Subject: [openbeos] Re: StyledEdit issues : text encodings,opentracker
integration, etc.


>
> 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