Summary:
Evas Textblock ellipsis is handled in a item.
When the ellipsis item is added in the text, some characters are cut off
considering width of ellipsis character.
But, it is handled in only one text item.
If there are many short text item, the ellipsis item can be cut off visually.
Fixes Phab ticket T1213
@fix
Test Plan: This commit includes test case.
Reviewers: woohyun, seoz, sohyun, tasn
Subscribers: herdsman, cedric
Differential Revision: https://phab.enlightenment.org/D1311
Summary:
In items loop of _size_native_calc_line_finalize,
last_it should be replaced with new item according to position.
But, visual_pos is not prepared and it is always zero in the function.
So, we need to update visual_pos.
And when textblock only has LTR text,
we can replace last_it according to item list sequence.
@fix
Test Plan:
It includes test cases using the following test case.
1. "i<b>。</b>"
2. "。<b>i</b>"
Reviewers: seoz, woohyun, sohyun, tasn
Subscribers: raster, herdsman, cedric
Differential Revision: https://phab.enlightenment.org/D859
Summary:
We can define a style tag as opener, closer and own closer.
If there is a markup tag that is matched to style tag,
it is reprocessed to format node inside of textblock.
But, when the format node will be converted to markup text,
'/' character can be appended to text at closer and own closer style tag.
Even if original markup tag does not has '/' character,
it will be appended according to format node information.
It makes some issue when compare input text with output text.
@fix
Test Plan: This commit includes test case.
Reviewers: woohyun, raster, sohyun, tasn
Subscribers: herdsman, cedric
Differential Revision: https://phab.enlightenment.org/D1037
Summary:
Word start/end works incorrectly when it goes to new line or line begins with spaces.
Ex: In elementary_test/Entry, place cursor at the end of line, press ctrl + right arrow keys: cursor moves to begin of next line. In this case, cursor should move to end of 1st word in next line.
Ex2: In elementary_test/Entry, add some spaces to begin of 2nd line (" uses markup"), place cursor at the first word ("uses"), press ctrl + left arrow keys twice, cursor moves to begin of 2nd line. In this case, cursor should move to begin of last word in 1st line.
This patch provides a fix by considerring next/previous text node to move cursor to correct place.
@fix
Reviewers: woohyun, raster, tasn
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D1140
Summary:
currently, normal orientation tests are only added.
I'm going to add flipped orientation tests as well after I put related code in jpeg loader (currently it's not supported)
Reviewers: raster, cedric, jpeg
CC: seoz, cedric
Differential Revision: https://phab.enlightenment.org/D1098
Summary:
This test should make the test suite fail. It sets "a<ps>b" and
"a<ps/>b" markups, and deletes the PS format. Essentially, these two
different markups should have the same result by this deletion. Instead,
only the <ps/> format gets deleted properly.
A follow-up commit is added with this as a fix.
Evas/Textblock: fix deletion of PS bug
Fixes an issue with deletion of "<ps>". Format deletion was only
performed for formats that are own-closers. This sets the paragraph
separator to be an own-closer format.
@fix
Reviewers: tasn
Reviewed By: tasn
CC: JackDanielZ, id213sin
Differential Revision: https://phab.enlightenment.org/D1046
Summary:
When item format is cutoff by ellipsis, *_cursor_format_item_geometry_get API
should be failed at the item position.
But, it can be success and returns abnormal geometry.
Reviewers: woohyun, tasn
CC: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D974
"f<color=#f00>i</color>f" could cause textblock to crash. It doesn't
crash anymore. It doesn't render the colours correctly either, but at
least this is the first step.
This is the start of fixing T1308
@bugfix
Summary:
This enables textblock to support more values other than 1.0.
For 0 <= ellipsis < 1.0, it splits the text such that it fits the
textblock's width. The ellipsis is relatively position according to the
ellipsis value, and characters are removed also relatively.
For example, a value of 0.5 will position the ellipsis right in the
center of the textblock's width, while removing characters equally right
and left from the center.
Basic approach to this feature was to do some work before the layout
process. We calculate the expected total width of the items, and by how
much we exceed from the textblock's width. Afterwards is it just some
careful work to set the boundaries of the width we want to cut, and
deciding which characters we need to removed to fulfill this requirement.
The rest is splitting the text and visually-removing the part we
need to cut.
This is all handled before any logical lines are created, so the
_layout_par function remains almost intact. A designated _ellip_prev_it
field in the Paragraph struct instructs after which item we place the
ellipsis item, if at all.
Note that we keep the fast path for ellipsis 1.0, as heavier work needs
to be done for the other values.
Added tests to evas_suite for a range of ellipsis values.
Also, multiline is unsupported at the moment.
@feature
Test Plan: Anything that uses Evas Textblock (single-line, please)
Reviewers: tasn, id213sin, raster
CC: cedric, JackDanielZ, raster
Differential Revision: https://phab.enlightenment.org/D905
Summary:
Some fonts has combination information for "ff".
When harfbuzz is enabled with the font, evas text ellipsis logic can be broken.
Reviewers: tasn, woohyun, cedric
Reviewed By: tasn
CC: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D870
Some comment/commit message improvements by TAsn.
Yes, it's a bad move. But I'd rather avoid breaking make check
for now until I have a proper test suite.
The script language has been changed to Lua, and so its
limitations and syntax are not the same. Remember this is a beta
API so it shouldn't even be exposed to normal apps.
This adds filter support to Image objects as well.
The exact same filters can run on Text and on Images
(provided some colorspace limitations are respected).
This basically adds:
- Support for RGBA input buffer
- Eo entry points for Image filter support
- Implement basic filter support in Evas_Image
Summary: Evas textblock can't cut off text properly when it has separated items.
Reviewers: tasn, woohyun, raster
Reviewed By: raster
CC: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D667
It seems that a different version of freetype is causing some different
values to be calculated for some glyphs. Also, we consider the whole
font list when calculating max ascent/descent, so there will always be
differences there.
This commit just laxes the tests, requiring the values to be at least
the values we expect from our font.
Fixes T1079
This happens with many texts. The issue occurs when the width of the
last char is larger than it's advance. Before this patch, we didn't the
width into account when calculating width, thus causing clipping issues
in some cases.
Force render into an Ecore_Evas, and check that the pixels
are valid:
- Not all transparent (can't really happen)
- Not all black (since there's a black rect behind the text)
- All valid premultiplied values (A >= R,G,B)
Yes, it's a bit slow. But at least it really checks something :)
Set filter on a text object and check the object's geometry.
Get the padding and the geometry so we're sure they match.
Also, pad_get would return 0 if the filter did not compile,
so this checks that these filters are valid.
This test uses some Devanagari text that should have more complex
clusters than what latin text can provide. This is a more complex
wrapping case that should be tested and haven't been tested until now.
In the previous commit, style padding has been changed, so
that lines don't get extra space just because there's a special
style (glow, ...)
This adds some test cases that check the actual geometry of the
lines relatively to each other.
NOTE: This test does not fail before the padding commits, as
_relayout_if_needed() adjusts the padding properly.
Summary: Added a test for range_text_get case on the text that include multi text node.
Reviewers: tasn, woohyun, seoz
CC: cedric
Differential Revision: https://phab.enlightenment.org/D398
Markup_get was misbehaving and returning wrong results with some escaped
chars. markup_to_utf8 was working correctly. Merged the code together
and now both are consistent and correct.
Thanks to WooHyun for reporting.
The tests were failing on jenkins (gentoo), and on arch, but passing on an
old ubuntu. Ubuntu patches freetype, and that's probably the reason for that
with the tests more lax, both work.
- re-enabling split BiDi cursor tests, disabled in 0d68ffbe;
ligatures tests are still disabled;
- change "fail_if" to "ck_assert_int_*",
because it prints error message with values;
- fixing usage of embedding LTR/RTL codes in tests;
Signed-off-by: Yakov Goldberg <yakov.g@samsung.com>
Some of tests fail on e5-jenkins-slave-x86_64-1.
Tests seem right and pass locally,
but not on the server.
Signed-off-by: Yakov Goldberg <yakov.g@samsung.com>
If query at x coord, which points to rigth half of LTR char,
next position will be returned. The same for left half of RTL char.
Signed-off-by: Yakov Goldberg <yakov.g@samsung.com>
The issue happens when selecting in strings that have both bidi and different
scripts in the same bidi run. E.g: "עבריתenglishрусскийעברית".
SVN revision: 83786