[GSoC] Character border

[Zolnai Tamás]

Hi all,

   It seems my proposal got into the selected ones, thanks for the
opportunity.

As some of list members know I am not a beginner with LO. I have
already done some work mostly with localization (kill sdf and
refactor\clean l10ntools). Additionally I have added a little feature which
is visible from the side of the users too (limitbox in Base).

On the summer, I will wrok with Writer, making possible using character
borders. It sounds simple, but it has more sides. The first thing that
comes to mind about character border is a simple four-sided border with the
given color, width and style.
   But It can be extended a bit, with adding different borders to the sides
or adding borders just to the selected ones (like table border). So it can
use no just as a border but as an underlining or overlining (with more
features which a simple one provide) but in extreme cases it can also use
as an unremoveable '|' separator. (well, I have no idea when it comes in
handy)
   The third part is using shadow as a special inhomogeneous border and
adding padding between the selected characters and the border.

   I added a bit detailed description of this feature, just to see what
territories it touch. So if anybody has ideas\advices about painting
lines\borders, adding new character attributes, extending filters or
anything linked with them, than - as the phrase goes - feel free to write
me.


Best regards,
Tamas
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Character border

[Cedric Bosdonnat]

Hello Tamás,

On Tue, 2013-05-28 at 18:16 +0200, Zolnai Tamás wrote:
> As some of list members know I am not a beginner with LO. I have
> already done some work mostly with localization (kill sdf and refactor
> \clean l10ntools). Additionally I have added a little feature which is
> visible from the side of the users too (limitbox in Base).

It will be great to have you working on the characters borders!

> On the summer, I will wrok with Writer, making possible using
> character borders. It sounds simple, but it has more sides. The first
> thing that comes to mind about character border is a simple four-sided
> border with the given color, width and style.

[...]

Well that is only the use case and it isn't that complex: if we can draw
the 4 borders, then any other case is pretty simple ;)

You should better see your task as the following steps:
  * Change the Character properties UI to add the existing "Borders"
page.
  * Write the borders definition into the SwFmt.
  * Change the layout to paint the borders. Borders will influence the
line height and spacing between characters. This part will probably be
the trickiest one. The code to paint borders is already implemented, but
changing the layout requires you to understand it first ;)
  * Persist the borders to the various filters. There is no
specification to do here as even ODF specifies these borders.

>I added a bit detailed description of this feature, just to see
> what territories it touch. So if anybody has ideas\advices about
> painting lines\borders, adding new character attributes, extending
> filters or anything linked with them, than - as the phrase goes - feel
> free to write me.

I think Miklos planned to have a kick-starting session with you: we'll
be able to discuss the details there. I once had a patch for the first
step, you'll find it attached, although I'm not sure it's still useful.

--
Cedric

commit 932ff3d1703b2b21d1c544815867bc803b5b92b2
Merge: 4a111ea a36dd99
Author: Cédric Bosdonnat 
Date:   Thu Aug 11 09:33:35 2011 +0200

On master: WIP Character borders

diff --cc cui/source/tabpages/border.cxx
index 98aeae8,98aeae8..457b671
--- a/cui/source/tabpages/border.cxx
+++ b/cui/source/tabpages/border.cxx
@@@ -1134,7 -1134,7 +1134,7 @@@ IMPL_LINK( SvxBorderTabPage, LinesChang
  sal_uInt16 nValid = VALID_TOP|VALID_BOTTOM|VALID_LEFT|VALID_RIGHT;
  
  //fuer Rahmen und  Absatz wird das Edit disabled, wenn keine Border gesetzt ist
--if(nSWMode & (SW_BORDER_MODE_FRAME|SW_BORDER_MODE_PARA))
++if(nSWMode & (SW_BORDER_MODE_FRAME|SW_BORDER_MODE_PARA|SW_BORDER_MODE_CHAR))
  {
  if(bLineSet)
  {
diff --cc svx/inc/svx/flagsdef.hxx
index 2b1b30d,2b1b30d..2692e08
--- a/svx/inc/svx/flagsdef.hxx
+++ b/svx/inc/svx/flagsdef.hxx
@@@ -35,6 -35,6 +35,7 @@@
  #define SW_BORDER_MODE_PARA 0x01
  #define SW_BORDER_MODE_TABLE0x02
  #define SW_BORDER_MODE_FRAME0x04
++#define SW_BORDER_MODE_CHAR 0x08
  
  // flags for SvxBackgroundTabPage
  #define SVX_SHOW_SELECTOR   0x01
diff --cc sw/inc/hintids.hxx
index afd57f3,afd57f3..1eac3d1
--- a/sw/inc/hintids.hxx
+++ b/sw/inc/hintids.hxx
@@@ -96,8 -96,8 +96,9 @@@ RES_CHRATR_BEGIN = HINT_BEGIN
  RES_CHRATR_RELIEF,  // 36
  RES_CHRATR_HIDDEN,  // 37
  RES_CHRATR_OVERLINE,// 38
--RES_CHRATR_DUMMY1,  // 39
--RES_CHRATR_DUMMY2,  // 40
++RES_CHRATR_BORDER,  // 39
++RES_CHRATR_DUMMY1,  // 40
++RES_CHRATR_DUMMY2,  // 41
  RES_CHRATR_END
  };
  
@@@ -123,27 -123,27 +124,27 @@@ RES_TXTATR_BEGIN = RES_CHRATR_END
 - META and METAFIELD must precede CJK_RUBY and INETFMT
   */
  RES_TXTATR_WITHEND_BEGIN = RES_TXTATR_BEGIN ,
--RES_TXTATR_REFMARK = RES_TXTATR_WITHEND_BEGIN,  // 41
--RES_TXTATR_TOXMARK, // 42
--RES_TXTATR_META,// 43
--RES_TXTATR_METAFIELD,   // 44
--RES_TXTATR_AUTOFMT, // 45
--RES_TXTATR_INETFMT, // 46
--RES_TXTATR_CHARFMT, // 47
--RES_TXTATR_CJK_RUBY,// 48
--RES_TXTATR_UNKNOWN_CONTAINER,   // 49
--RES_TXTATR_DUMMY5,  // 50
++RES_TXTATR_REFMARK = RES_TXTATR_WITHEND_BEGIN,  // 42
++RES_TXTATR_TOXMARK, // 43
++RES_TXTATR_META,// 44
++RES_TXTATR_METAFIELD,   // 45
++RES_TXTATR_AUTOFMT, // 46
++RES_TXTATR_INETFMT, // 47
++RES_TXTATR_CHARFMT, // 48
++RES_TXTATR_CJK_RUBY,// 49
++RES_TXTATR_UNKNOWN_CONTAINER,   // 50

Re: [GSoC] Character border

[Zolnai Tamás]

Hi Cedric,

Well that is only the use case and it isn't that complex: if we can draw
> the 4 borders, then any other case is pretty simple ;)
>

Yes, I just add the use case, so all of us can got ideas about it without
having an intense knowledge about the implementation. And yes I hope so
that will simple.


> You should better see your task as the following steps:
>>   * Change the Character properties UI to add the existing "Borders"
>> page.
>>   * Write the borders definition into the SwFmt.
>>   * Change the layout to paint the borders. Borders will influence the
>> line height and spacing between characters. This part will probably be
>> the trickiest one. The code to paint borders is already implemented, but
>> changing the layout requires you to understand it first ;)
>>   * Persist the borders to the various filters. There is no
>> specification to do here as even ODF specifies these borders.
>
>
 Thanks for the advices.

I think Miklos planned to have a kick-starting session with you: we'll
>> be able to discuss the details there. I once had a patch for the first
>> step, you'll find it attached, although I'm not sure it's still useful.
>
>
 Yes, I've already spoken with Miklos, but as I said, I wait ideas from
anybody, not just from the proficients, but of course the latters will be
the most helpfull for the implementation.

Best regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Character border, 6. week

[Zolnai Tamás]

Hi all,

   The previous week I don't make the progress that I planed, but learnt a
lot about the character attributes, font construction and portion handling.
So I say this week was useful.

   The most time of the week I spent with border merging, which makes
neighbouring text portions' border connected, when they has same border and
same height, even if they have different font. This problem was make me to
look through the whole working flow of character attributes, from attribute
sets and stacks to building portions.
Finally I use SwAttrIter, which constructs the font from the character
attributes and makes enable it for other codes. This solution is useful
because text portions are handled by different classes (painting ->
SwTxtPainter, size -> SwTxtFormatter, text cursor -> SwTxtCursor) and the
only connection point of them is the generated font. On the other hand,
line break makes distinct text portions with same underlining character
attributes, so I have to solve this case in an other way.

Besides this I fix two bugs connected to the code, which I look into :
1, Text cursor skipped the last character of the line, so when user click
into the right margin than the cursor were placed before the last character
and not after it. In general the last character is a space and that's why
this is skipped, but there are some extreme case (e.g. link, long word in a
short line) when no reason to skip the last character.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=c8b4ffc2adcc744c0d7d5e68944439238828692b
2. Drop caps background were shifted upward. This bug is really visible for
example with Q letter, because this letter have big part hanging into the
descender area.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f47b46959267a25195d4f3f5602ca638bb14c58

Best Regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Character border, 7. week

[Zolnai Tamás]

Hi all,

   In this week I managed to solve the special cases of character border by
and large (vertical text, drop caps, numbering and other fields). There are
still some problem with the feature.
   The most recent is that the SwpHints array, which contains the character
attributes, seems initialized wrong somewhere in the code. In general
SwAttrIter uses this array expected that this is indexed from 1 and not
from 0, but when I change the attributes of the first character of the
paragraph, then the attribute iterator will find the first character
attribute at position 0 and this makes the iterator a bit confused. It
doesn't update the corresponding font, which makes the border merge not to
work, however I can't find any other bug caused by this wrong indexing.

Besides bug fixing next steps will be:
- UNO API
- border margin


Best regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Character border, 8. week

[Zolnai Tamás]

Hi all,

What have done in the previous week:
- Border spacing/padding
- UNO API for border and padding
- Some code scrubbing to get ready for shadow implementation
- ODF filter (partially)

Plans for this week:
- Write tests for ODF filter
- Add a better solution for border merge (one border to distinct text
portions)
- Implement border shadow


Best regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Character border, 9. week

[Zolnai Tamás]

Hi all,

In this week I dealt with these questions:
- How to write Writer tests? (API tests which seems to be more and more
unused (qadevooo), filter tests using UNO API)
- How to handle special properties during export/import? (e.g. Drop Caps
character style, solve* Bug
43807)*
- What is RSID (character and paragraph) and how this attribute changes
portion building?
- How to use a global algorithm to solve border merge on a better way?
(SwTxtFormatter::BuilPortions)
- How to reduce drop caps undefined behaviour? (In some case drop caps
letter changes its position unexpectedly. I solved the case of big padding.)
- Should border have the same background as the content? (LO follows the
HTML box concept (yes))


Best regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Character border, 10. week

[Zolnai Tamás]

Hi All,

In the previous week I've done the next things:
- Implement border shadow.
- Finish ODF filter (write OASIS ODF proposal)
- Write help for character border
- Fix two bugs:
   - Borders with different styles were merged to one borderline primitive
(solid-dashed-dotted)
   - The relatively new border line style called "fine dashed", wasn't
exported/imported into ODF.

Next weeks, I will work with other filters like DOC, DOCX, RTF and so on.

Best regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Character border, 10. week

[Miklos Vajna]

Hi Tamas,

On Tue, Aug 27, 2013 at 10:57:40AM +0200, Zolnai Tamás 
 wrote:
> In the previous week I've done the next things:
> - Implement border shadow.
> - Finish ODF filter (write OASIS ODF proposal)
> - Write help for character border
> - Fix two bugs:
>- Borders with different styles were merged to one borderline primitive
> (solid-dashed-dotted)
>- The relatively new border line style called "fine dashed", wasn't
> exported/imported into ODF.

Excellent, thanks for these! :-)

> Next weeks, I will work with other filters like DOC, DOCX, RTF and so on.

As we discussed on IRC, HTML filter can also be updated, as that
format supports char borders as well.

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Character border, 11.-12. week

[Zolnai Tamás]

Hi all,

In the previous two weeks I implemented next things:
- Extend character border for tabulators.
- Write filters:
  - HTML
  - MS filters (DOCX, RTF, WW8)

Next week, I will fix some small bugs belonging to character borders, write
documentation and do some tests.

Best regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Character border, 11.-12. week

[Miklos Vajna]

Hi Tamás,

On Sun, Sep 08, 2013 at 12:58:35PM +0200, Zolnai Tamás 
 wrote:
> In the previous two weeks I implemented next things:
> - Extend character border for tabulators.
> - Write filters:
>   - HTML
>   - MS filters (DOCX, RTF, WW8)
> 
> Next week, I will fix some small bugs belonging to character borders, write
> documentation and do some tests.

That's great! Here are a few comments:

- assertEqualBorder() -> CPPUNIT_ASSERT_EQUAL_BORDER(): in C++, in
  general inline functions are preferred over macros. If the intention
  is to get the place where the real problem is, run the unit test in
  gdb, and get a backtrace.
- If you deal with colors in unit tests, I think writing them in hex
  form is much more readable (16711680 vs 0xff). Or in case it's a
  common color, even better: COL_RED
- sw/source/filter/ww8/attributeoutputbase.hxx: Please avoid using
  'using' in header files, we only do that in cxx files, hxx files have
  all the namespaces written out for better readability.

Other than that, great progress, thanks! :)

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Character border, 11.-12. week

[Zolnai Tamás]

Hi Miklós,


> - assertEqualBorder() -> CPPUNIT_ASSERT_EQUAL_BORDER(): in C++, in
>   general inline functions are preferred over macros. If the intention
>   is to get the place where the real problem is, run the unit test in
>   gdb, and get a backtrace.
>

I looked up how to write new unit test macros
http://cppunit.sourceforge.net/doc/lastest/group___assertions.html and
http://cppunit.sourceforge.net/doc/lastest/struct_asserter.html
and rewrite the mentioned macro using an inline function inside it, so it
becomes more safe, which is the biggest advantage of using functions
instead of macros. Plus with it, the assertion will point to the right
place.
I pushed the diff to gerrit, if you have other comments to it:
https://gerrit.libreoffice.org/#/c/5885/


> - If you deal with colors in unit tests, I think writing them in hex
>   form is much more readable (16711680 vs 0xff). Or in case it's a
>   common color, even better: COL_RED
>

It seems in LO souce code COL_RED not equal with 0xff. I tried to use
it in the unit tests, but they failed. So I keep at hex form.


> - sw/source/filter/ww8/attributeoutputbase.hxx: Please avoid using
>   'using' in header files, we only do that in cxx files, hxx files have
>   all the namespaces written out for better readability.
>

Ok,

Best regards,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice