On Sat, 13 Aug 2005 13:49:11 +0900 Carsten writes:
> On Sat, 13 Aug 2005 00:24:25 -0400 Tianran Chen
> <[EMAIL PROTECTED]>
> babbled:
>
> > i did see the utf8 code. but utf8 is far from universal, now one
> of my
> > handheld computer uses alot utf16 and GB, which
> evas_commont_utf8_*
> > cannot handle. unicode is not yet 100% functional for CJK yet.
>
> the problem is - the evas api is DEFINED to accept utf8 as all
> strings. all
> strings are utf8 as far as it is concerned. it expects them in utf8
> and will
> return them in utf8. so if you have anything that is not utf8 and
> you want to
> give it to evas - you must convert it to utf8 first, and vice-versa.
> utf8 is
> able to cover all unicode code-point space as as such so it is
> sufficiently good
> to do everything. :)
>
> > > ooh - what you may not notice is... the string is utf8... yes -
> i have been
> > > bad and just walked char pos's and not done proper utf8 "Walks"
> when running
> > > around the string (yet) i'm fixing that up - i was just getting
> it working
> > > with minimum hassle. i'm making it utf8 "correct". utf8
> basically means it's
> > > going to handle all languages and all unicode code points - at
> once. so
> > > there is not much need of that :)
> >
> > > that's not possible as the typesetting needs a way to draw - and
> that means
> > > the engine layer needs to be involved as otherwise they have no
> possible way
> > > to draw... and if the engine layer cannot do this... you're
> pretty screwed
> > > :) also the fact is - i don't see a lot of typesetting engines
> turning up.
> > > this stuff is HARD and PAINFUL. it's not done often.
> >
> > hmm... i have to take a closer look at your code, i don't quite
> see
> > that why, but don't bother to answer me.
>
> trust me :)
>
> > > that is technically what they _layout() function does (the first
> bit) -
> > > until someone has another typesetting engine that would be
> compatible and do
> > > as much/more than the layout code... i don't see much need to
> work hard on
> > > this - as explained above. practically speaking it's going to be
> working in
> > > a void - i have no generic "typsetting api" to mimic or go by. i
> have no 2nd
> > > or 3rd or 4th typsetting engine to use for testing. :)
> >
> > fair enough. i really need vertical & right-to-left typesetter, so
> if
> > i can find some time during the fall semester, i will try to make
> one.
>
> you need vertical do you? hmm - here in japan they are more than
> happy to do
> left to right any time. i thought it was the same in china and
> korea. so i have
> ignored top to bottom. i do know fo right to left issues and frankly
> that is my
> biggest problem at the moment. that involves having to address not
> just
> textblock, but evas's core text drawing routines as these ONLY draw
> left to
> right. i basically have not addressed right to left as i speak none
> of these
> langauges (arabic, hebrew etc.) and it is a bit more complex with
> arabic for
> example using composed characters (1 char composed of multiple
> unicdoe glyphs
> overlayed) and i actually don't know what it is MEANT to look like
> etc.
> especially mixed right to left and left to right languages - eg
> quote english
> within arabic sentences, or vice-versa.
>
You could make this work by letting such 'layout engines'
use smart objects and be given as external libs, ie. libs like edje.
You'd create, via the particular text format/layout lib, objects
of whatever format type you want (say text/html), and when a 'string'
of text is 'set' to a text-format block object, the lib would create
the needed evas smart object and 'parts' which are evas text objects
with text/font-face/font-size/color set on such objects as the lib
choses,
and with each such part giving the pos it should be rendered at.
Things like underline/overstrike are extra line objects, etc.
This might be a bit slow for top-bottom text and such.
The best way to do this would probably be by letting such 'layout
engines' be "glyph-servers", which would hand evas (from a given
input string and format type) a sequence of glyph masks plus glyph
geometry (leading/size/advance) plus color plus other primitive
elements as needed (lines etc), where the layout engine is then
responsible for obtaining the correct fonts, glyphs, etc., and also
for caching these...
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
