Summary:
This patch defines the way style property will work at canvas_text object
1- Changing canvas_text style property using Font/Format/Style interfaces or with efl_canvas_text style property are the same.
Example:
```
efl_text_font_set(tb, "Arial", 30);
//is same as
efl_canvas_text_style_set(tb, "font=Arial font_size=30");
//which means calling
char * font;
int size;
int font_size;
efl_text_font_get(tb, &font, &size);
// calling this after any of the top two functions will return same result
```
2- style_get_property
Will return string that contains full details about all the current applied style at canvas_text level.
3- style_set_property
Will only override passed styles and leave everything else as it is
```
efl_canvas_text_style_set(tb, "font=Arial"); // overrider font name to Arial and leave everthing else
efl_canvas_text_style_set(tb, "font_size=30"); // overrider font size to 30 and leave everthing else (font name will stay arial)
```
Reviewers: ali.alzyod, woohyun, tasn, segfaultxavi, bu5hm4n, zmike
Reviewed By: woohyun
Subscribers: zmike, bu5hm4n, segfaultxavi, a.srour, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10607
This code is filled with out of bounds accesses now after the reverted
patch. All those base_char+1, itr+1 etc. in
evas_common_font_query_run_font_end_get() are accessing BEYOND
the end of the run. textgrid shows this instantly to fall over as it
uses single unicode codepoint chars with no nul terminator. As this
api takes an explicit run_len we should never access beyond the end of
the run_len.
Please revisit this code and keep in mind proper memory/bounds
accessing. If there was ano run_len and it assumed strings were
regular strings that had to be nul terminated... then it might be ok,
but not here.
of course if i put in guards for these +1's then it ends up in
infintie loops, so enough debugging and send it back for a rethink. :)
....
Revert "evas_object_textblock: add support for variation sequences"
This reverts commit 46f2d8acdc.
so if you use sw and gl enignes in a process and have color font
glyphs.. *BOOM* because the color glyph code used ext dat that was
intended for engines to extend with a gotcha of "only 1 engine can
extend this"... commented already.
so this unfortunately adds an extra ptr per glyph to store color data
explicitly. but now it both renders right and doesn't crash. we still
have a limit of 1 engine alone can extend glyphs with ext_dat though.
@fix
update font processing to handle variation sequences unicodes to select proper glypg in respect to variation seqences
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D9053
Public symbols were defined internal to Evas/Elementary on macOS, making
the link of external modules unfeasible.
- EAPI was messed up by an invalid inclusion of evas_text_utils.h, making
some symbols private instead of public.
- A similar issue was present in evas_font_draw.c, where the symbols
were directly imported without the proper definition of EAPI.
- Elementary.h did include some eo-generated headers, but for windows
only. It should not been restricted to windows, as it allows to export
symbols to external modules.
Fixes T6448.
Build failed with LKI not found, as a symbol, but it's a macro.
Copy & pasted from evas_common_private.h
How can this work on one platform and not another? I don't get it...
Summary:
dev branch : devs/subhransu/font
The Final goal is to move the evas_font module to ector so that both ector and evas can reuse the code.
make the api simple so that sam eapi can be used by evas_textblock and ector text.
This is the 1st stage to achive that gola, first remove the evas internal dependancy as much as possible before moving to ector library.
Reviewers: jpeg, raster, herdsman, cedric, id213sin
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D5419
This is modifying how a rarely used environment variable that sets the
DPI used for font sizing is parsed. The previous form remains valid, of
course. Note that EFL tends to use "scaling" instead of this DPI. The
font DPI is useful for me to open up a terminology window with almost
the same size as my IDE's code viewer.
Use case:
export EVAS_FONT_DPI=95x94 terminology
Note:
I still don't get a 1:1 match with Qt's rendering, and in fact
94x95 works better than what 95x94 (which is reported by xdpyinfo).
Interesting though :)
@feature
Summary:
When evas selects a strike of embedded bitmap font,
calculate ratio and use it for scaling embedded bitmap.
@feature
Reviewers: jpeg, tasn, woohyun, raster, herdsman
Reviewed By: raster
Subscribers: charlesmilette, Francesco149, cedric
Differential Revision: https://phab.enlightenment.org/D2713
Summary:
If the last item before ellipsis item has bigger width than its advance,
evas_common_font_query_last_up_to_pos() function can find wrong ellipsis position.
When Evas finds a position for non last item, Evas must care about additionally
available space for glyph's width of the given x position.
ex) the last item's glyph before ellipsis item has a tail to draw above the ellipsis item.
@fix
Test Plan:
Test case will added as comment.
(Becasue of font license problem.)
Reviewers: herdsman, raster, jpeg, woohyun
Subscribers: cedric, Blackmole
Differential Revision: https://phab.enlightenment.org/D4727
some font glyphs are still allocated after tyhe last gl window is
freed which means we can't make current anymore to free textures after
that. this fixes that by flushing gl texture info from the font cache
when the last gl windows are gone.
@fix
This is a long awaited feature that has been requested years ago.
Fontconfig finally added the support needed to make it happen, so here
it is.
I added a fontconfig query to look for similar fonts in case we loaded a
font from eet/edje/file(no fontconfig). This now works quite well.
Still missing: if you load a bold/italic/whatever font directly (set the file)
without putting ":weight=bold" you will not get run-time emboldenment if
only non-bold fonts are found.
This unfortunately depends on very recent fontconfig version (#ifed out
when unavailable), so only people with fontconfig >= 2.11 will enjoy
this feature.
this changes the internal encoding of font glyphs in evas to use 4bit
uncompressed if small, or 4bit rle (run length encoded) if larger.
this caves at least 50% of memory on fonts - and more if bigger. with
large fonts (40-80pixel size) we can save in the region of 80% of
memory used for glyphs. this also happesn to allow speedups in
rendering too.
This patch should make us get a reference on images, maps and glyphs
which are sent in a command to the render thread. Before we were doing
some useless ref and unref operations.
SVN revision: 82666
This is in preparation for threaded render landing: the render thread will
hold a reference to a text object's glyphs while it hasn't been rendered
yet (and will drop that reference after drawing). This changes the internal
API a little bit (evas_common_font_rgba_draw() now takes an Evas_Glyph_Array
instead of an Evas_Text_Props).
SVN revision: 81183
This patch refactors common code for font draws - so that it can be used
by other engines and *threaded* X11.
Signed-off-by: Paulo Alcantara <pcacjr@profusion.mobi>
Patch by: Paulo Alcantara <pcacjr@profusion.mobi>
SVN revision: 79853
I've tested make -j 3 install and it works nicely
I've tested expedite with software and opengl xlib,
and it works. Not tested other engines, so please
report any problems (engines or other) on the ML.
TODO: examples and tests, I'll add them later
ISSUE: Eina_Unicode size check. It indirectly depends on
eina_config.h, which is created at the end of the
configure script. So its size is always 0. I don't
know how that size is used, so I can't do a lot,
for now.
SVN revision: 78895
Ali Alzyod
abdulleh Ghujeh
Carsten Haitzler
Marcel Hollerbach
Christopher Michael
Vincent Torri
Jean Guyomarc'h
Jean-Philippe Andre
subhransu mohanty
Youngbok Shin
Tom Hacohen
Ulisses Furquim
Leandro Pereira
Paulo Alcantara