Re: [E-devel] the implementation of etox seems slow
On Sat, 13 Aug 2005 11:33:08 -0400 Tianran Chen [EMAIL PROTECTED] babbled: 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. :) fair enough, i guess this is why i should read the document or read the source. a lot ISNT in the documentation :( 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. yeah, believe or not. most chinese now uses left-right layout, same for korean. but i wrote a small typesetter for windows, which makes acient chinese and mongolian script looks right. now i want to port it to linux. nice! :) that'd be cool- well if you want, follow my textblock2 work - its in cvs. basically you will want a variant on the _layout() function that does top to bottom i think. how stable is the textblock(2) api now? maybe i can do sth base on it. not stable at all. i'm working on it. but its best to get into it NOw while its building. there is a lot less to understand. -- Regards, Tianran Chen -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- 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
Re: [E-devel] the implementation of etox seems slow
On Sat, 13 Aug 2005 05:34:24 -0400 Jose O Gonzalez [EMAIL PROTECTED] babbled: On Sat, 13 Aug 2005 02:16:49 -0400 Jose writes: 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. Actually evas could easily draw vertical (ie. top-bottom) text quite easily, as this merely requires advancing the 'pen' by each glyph's advance in both x and y components (same for kerning deltas) - right now it only advances the x coordinate. I haven't looked at ft2 (last ft I looked at was ft1), but it's likely that if the font is meant to be drawn vertically then ft2 will give the required glyph y advances.. it'd definitely be possible. we'd need options for it, but it's possible. but on a higher level the layout code for textblock for exmaple also thinks left to right advancinc to the right in x then wrapping onto a new line. to do top to bottom it needs to think differently and let the height of the object control wrapping not the width. as best i have seen NO one EVER mixes top to bottom and left to right WITHIN the same block of text. they may make a whole new page section that formats independently or a new page - but never within a block. so this would be an option i guess for the layout enigne - use a different layout routine. as for right to left. there are many examples of mixed left to right and right to left text. this is easier to mix, but also requires special treatment. i'd LOVE someone who is really inetersted in these to take them head on and do them. so far in the history of my coding expeditions, right to left and top to bottom text have been requested 2 times and once - respecitvely. In any event, font/text issues are most definately a *huge* pain, and it would require some time looking into ft2 and such in order to get a good idea of what's involved.. theres another problem. combined glyphs. where 1 characters is made up fo 2 or 3 glyphs drawn 2 or 3 tumes on top of eachother which are a sequence of 2 or 3 characters. i understand arabic is the offender here. that makes life a REAL pain. But for things like html, rich-text, plain-text, funky-text, etc, ... formatting schemes, it should be possible (and likely preferable) to achieve such formatting schemes with external 'smart-libs' and some modifications to evas' core glyph drawing (and possibly font/glyph caching). it'd be nice - but u'd need a generic way to plug them in - and thats not easy. --- 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- 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
Re: [E-devel] the implementation of etox seems slow
On Sat, 13 Aug 2005 02:16:49 -0400 Jose O Gonzalez [EMAIL PROTECTED] babbled: 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... i think it's better done within evas as its insanely more efficient. evas is not tuned to handle very high object counts well. the idea is, as tome goes on more will be rolled into evas basic objects so things get more efficient. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- 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
Re: [E-devel] the implementation of etox seems slow
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
Re: [E-devel] the implementation of etox seems slow
On Sat, 13 Aug 2005 02:16:49 -0400 Jose writes: 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. Actually evas could easily draw vertical (ie. top-bottom) text quite easily, as this merely requires advancing the 'pen' by each glyph's advance in both x and y components (same for kerning deltas) - right now it only advances the x coordinate. I haven't looked at ft2 (last ft I looked at was ft1), but it's likely that if the font is meant to be drawn vertically then ft2 will give the required glyph y advances.. In any event, font/text issues are most definately a *huge* pain, and it would require some time looking into ft2 and such in order to get a good idea of what's involved.. But for things like html, rich-text, plain-text, funky-text, etc, ... formatting schemes, it should be possible (and likely preferable) to achieve such formatting schemes with external 'smart-libs' and some modifications to evas' core glyph drawing (and possibly font/glyph caching). --- 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
Re: [E-devel] the implementation of etox seems slow
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. :) fair enough, i guess this is why i should read the document 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. yeah, believe or not. most chinese now uses left-right layout, same for korean. but i wrote a small typesetter for windows, which makes acient chinese and mongolian script looks right. now i want to port it to linux. how stable is the textblock(2) api now? maybe i can do sth base on it. -- Regards, Tianran Chen --- 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
Re: [E-devel] the implementation of etox seems slow
* opaque string buffer. allow the use of other fast string libraries like
vstr.
can you explain in more detail? textblock is intended for:
if i'm not mistaken, the string buffer is now string of [char] and is
manipulated throught [str*] functions. i suggest use some opaque
type (say call it [str_t]), and manipulated it only via a small set of
functions (say [strbuf_*]). these types and functions are defined in
separated header files.
the purpose for this is so that users can compile textblock using
different kind of strings, either for different language (unicode or
native code, face the reality, there are just no standard for
non-western languages) or for better performance by using some fast
string library (like vstr for example).
1. text display where more than a single line of plain text is needed
(formatting, multiple fonts, styles, sizes, multiple lines etc). ie -
something
like what a web browser does.
2. small to medium sized text lumps (1-2000 lines of text or so)
3. text editing display back-end (easy enough to make an editable widget on
top
of textblock)
* external typesetting engine. allow textblock to be used for both
fast text rendering to serious typesetting, even rendering
mathematical equations.
that's hard as evas's text rendering isn't capable of things like transforms
on
the text (rotation, scale, shear etc.)... so it's kind of moot... :)
is is possible to just make textblock a text render and let
separate, external typesetting engines to take care of the rest. a
usecase goes like this:
{user alter text}:
* user alter text
* textblock ask typesetting engine to typeset
* engine obtain font information via textblock
* engine do typesetting: calculate the location of each bit of text
(this process maybe clipped)
* done
{evas render object}:
* evas ask textblock to render a region
* textblock draw each bit of text on canvas according to what engine
had provided.
* done
this way, with no extra work, allow textblock to be more flexible.
--
Regards,
Tianran Chen
---
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
Re: [E-devel] the implementation of etox seems slow
On Fri, 12 Aug 2005 23:30:22 -0400 Tianran Chen [EMAIL PROTECTED]
babbled:
* opaque string buffer. allow the use of other fast string libraries like
vstr.
can you explain in more detail? textblock is intended for:
if i'm not mistaken, the string buffer is now string of [char] and is
manipulated throught [str*] functions. i suggest use some opaque
type (say call it [str_t]), and manipulated it only via a small set of
functions (say [strbuf_*]). these types and functions are defined in
separated header files.
the purpose for this is so that users can compile textblock using
different kind of strings, either for different language (unicode or
native code, face the reality, there are just no standard for
non-western languages) or for better performance by using some fast
string library (like vstr for example).
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 :)
1. text display where more than a single line of plain text is needed
(formatting, multiple fonts, styles, sizes, multiple lines etc). ie -
something like what a web browser does.
2. small to medium sized text lumps (1-2000 lines of text or so)
3. text editing display back-end (easy enough to make an editable widget on
top of textblock)
* external typesetting engine. allow textblock to be used for both
fast text rendering to serious typesetting, even rendering
mathematical equations.
that's hard as evas's text rendering isn't capable of things like transforms
on the text (rotation, scale, shear etc.)... so it's kind of moot... :)
is is possible to just make textblock a text render and let
separate, external typesetting engines to take care of the rest. a
usecase goes like this:
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.
{user alter text}:
* user alter text
* textblock ask typesetting engine to typeset
* engine obtain font information via textblock
* engine do typesetting: calculate the location of each bit of text
(this process maybe clipped)
* done
{evas render object}:
* evas ask textblock to render a region
* textblock draw each bit of text on canvas according to what engine
had provided.
* done
this way, with no extra work, allow textblock to be more flexible.
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. :)
--
Regards,
Tianran Chen
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多 [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
---
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
Re: [E-devel] the implementation of etox seems slow
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. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) --- 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
[E-devel] the implementation of etox seems slow
i am still new to e17, so please do not mind my ignorance. the current implementation of etox uses a evas object for each bit of text. this is fine for static text. but for large text that changes frequently (say for web browser, or word processor, even) this seems quite slow. inserting a single letter can cause all evas objects to be reseted or even recreated. will it be better to let etox be some parallel object as etext or etextblock? -- Regards, Tianran Chen --- 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
