Summary:
It adds evas_object_paragraph_direction_set, get APIs.
The APIs set or get paragraph direction to/from the given object.
It changes BiDi calculations and affect the direction and aligning of text.
It doesn't have any effect to text without Fribidi library.
The default paragraph direction is EVAS_BIDI_DIRECTION_INHERIT.
If dir is EVAS_BIDI_DIRECTION_INHERIT, paragraph direction is changed
according to smart parent object. If there is no smart parent object,
paragraph direction works as EVAS_BIDI_DIRECTION_NEUTRAL.
@feature
Test Plan:
Test cases included to the following files.
- evas_test_textblock.c
- evas_test_text.c
- evas_test_object_smart.c
Run "make check".
Reviewers: woohyun, raster, herdsman, tasn
Subscribers: c, raster, cedric
Differential Revision: https://phab.enlightenment.org/D1690
Summary:
If textblock has linegap and multi language, ascent/descent calculation is
incorrect.
In _layout_format_ascent_descent_adjust(), descent is accumulated.
(for example, for a line gap of 50, the first line gap is more than 100)
Test Plan:
Textblock has "linegap=50" and multi language (ex.
"This is a test suite for line gap -
ഈ ലൈൻ വിടവ് ടെസ്റ്റ് ടെസ്റ്റ് ടെസ്റ്റ് ടെസ്റ്റ് ഒരു പരീക്ഷണ വെയര് ")
Added test suite in evas_test_textblock.c file.
Reviewers: tasn
Subscribers: subodh6129, cedric
Differential Revision: https://phab.enlightenment.org/D3311
This fixes a scenario in which paragraphs in the current layout still
store visual lines from the previous layout. This is possible if the
text uses an ellipsis format, allowing the layout work to stop at a
certain paragraph. This inconsistency affects some query functions that
consider lines which may be irrelevant in the current layout.
Test Case: see added test case to evas_suite.
@fix
Summary:
Introducing a new feature for Evas Textblock. This allows the layout to
wrap around other evas objects.
The following API is added:
- obstacle_add
- obstacle_del
- obstacle_update
Evas objects can now serve as textblock obstacles, if positioned and
visible on the text area. The text will wrap around the obstacles
according to the wrapping mode set to it.
This also modifies the current wrapping code to handle obstacle wrap
points as well. The wrap index query function is modified so that
forward-scanning (specific cases) may be disabled when treating
obstacle wrap point.
RTL text is currently unsupported by this feature.
Consult added docs and example for usage.
@feature
Test Plan: Evas example and test in evas_suite are provided with this.
Reviewers: tasn
Subscribers: raster, JackDanielZ, cedric
Differential Revision: https://phab.enlightenment.org/D2405
This fixes a case with wrapping, where the text has a mixture of 'none'
and 'word' wrapping modes, and the layout function decides to
roll-back a few items.
The test case is added to the evas_suite.
This might not be a common case, or even a case we had defined a proper
behavior to, but since it causes an infinite loop, it needs to be fixed.
@fix
Summary:
For showing text error like spell error thick underline is used hence added the underline height support.
@feature
Test Plan: test case added in evas textblock test.
Reviewers: raster, shilpasingh, tasn
Subscribers: govi, rajeshps, cedric
Differential Revision: https://phab.enlightenment.org/D2531
TAsn comment: I wonder if the format should be renamed to
underline_relheight instead of height. If you have any thoughts, please
let me know.
Summary:
The selection performance is slow if we select large chunk of text.
This is caused by many rectangles created and deleted.
This patch provides a way to improve it by combine selection rectangles
of line in middle into one rectangles (i.e, if we have N lines,
the selection rectangle for lines 2 to N-1 will be combined into one.)
@feature
Reviewers: raster, cedric, tasn
Subscribers: herdsman, woohyun, cedric
Differential Revision: https://phab.enlightenment.org/D1508
Summary:
If a RTL textblock has right margin, text is wrongly placed
(right margin is moved to left).
This patch fixes this issue.
Test cases are also added to test text position with margins.
@fix
Reviewers: tasn, herdsman
Subscribers: woohyun, cedric
Differential Revision: https://phab.enlightenment.org/D1691
Summary:
Currently, in cursor geometry get function, the text direction is not
returned if cursor is under cursor.
This patch fixs it by returning text direction for under cursor.
@fix
Reviewers: tasn
Subscribers: herdsman, cedric
Differential Revision: https://phab.enlightenment.org/D1505
Summary:
This fixes an issue that causes BiDi text to get wrapped even when
resizing the textblock to its native size.
The way we find the last visual item in the native line is wrong. The
'visual_pos' describes the visual position in the formatted layout, in
which wrapping may occur. So, this is really bad to use it for native
width calculations as well.
Also, there's no need to actually reorder the line - we just need the
last visual item.
This adds and uses a function very similar to _layout_line_reorder, in
which we retrieve the last visual item in the native line. This
function does not do any actual reordering, as the native layout is
disposed of after calculation is done.
Also, added GET_ITEM_LEN macro for convenience.
Fixes T1532
@fix
Test Plan: Added to evas textblock test suite in this patch
Reviewers: tasn
Subscribers: id213sin, JackDanielZ, cedric
Maniphest Tasks: T1532
Differential Revision: https://phab.enlightenment.org/D1353
Summary:
In some cases of char or word wrapping, an empty line might be
accidentally added at the end of the paragraph. That line contains
no items. Of course, this line should not exist.
One outcome of this is that it causes wrong height values of the
paragraph, when the finalizing code uses the
_layout_last_line_max_descent_adjust_calc, which in turn
looks at that empty line to calculate the descent values.
@fix
Test Plan: Char-wrap and word-wrap tests to test suite included in this revision.
Reviewers: tasn
Subscribers: JackDanielZ, cedric
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D1444
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.
And there was a bug in the patch when text is displayed in two lines or more.
The bug is also fixed.
Fixes Phab ticket T1213
@fix
Test Plan: This commit includes test case.
Reviewers: woohyun, seoz, sohyun, tasn, raster
Subscribers: cedric, herdsman
Differential Revision: https://phab.enlightenment.org/D1360
This tests that even with multiline ellipsis, the ellipsis in the second
line is not overdone (i.e it only does ellipsis as needed).
This is a test for something we found out when we applied D1311 (for T1213).
This patch fixes an issue causing text to be cut off in some cases.
The problem was that we were calculating line width and alignment before
we did any bidi calculations, which in turn caused us to use the wrong
text items for those calculations.
Many thanks to Daniel Hirt for investigating this deeply, finding all
the nitty-gritty and generally pointing me to where the problem is.
Daniel also provided the test case.
His patch (D1291) was close, but not enough.
Fixes T1496
@Fix
This reverts commit d408408283.
this breaks mult-line "long" filenames in efm. 2nd line is just ...
for almost all of them (ones that are actually in need of 3 or more
lines). break break! REVERT!
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:
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: 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.
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.
Youngbok Shin
Daniel Hirt
Minwoo, Lee
Tom Hacohen
Vladyslav Shevchenko
Subodh Kumar
Thiep Ha
Thiep Ha
Carsten Haitzler
Jean-Philippe Andre