Re: chained editeng: Add TextChainFlow related files

[Matteo Campanelli]

No strong feelings. :)
[Ouch: I left all those XXX comments?]

On Wed, Jun 29, 2016 at 5:43 AM Thorsten Behrens 
wrote:

> Stephan Bergmann wrote:
> > > +// XXX
> > > +bMustMergeParaOF = true; // XXX: Experiment: no deep merging.
> >
> > should that be removed?
> >
> Unless Matteo feels strongly - yeah.
>
> Cheers,
>
> -- Thorsten
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Impact of merging feature/chained-text-boxes to master

[Matteo Campanelli]

Hi all,

this is to describe some changes (in code and behavior) that should occur
merging branch  "feature/chained-text-boxes" to master.
The branch implements (a prototype of) text box chaining: the possibility
of having  logically linked text boxes in Draw (and potentially Impress) so
that text content beyond what box size allows goes automatically to the
next link. (And, the other way around, when space becomes available in
previous links this also gets filled with text from "next" boxes).

What was done (Main Blocks of Code Change)
---
1a) Detection of overflow/underflow of text (editeng);
1b) Changes in how box sizes are computed for chainable boxes (SdrTextObj
in svx/svdraw. Specifically this commit

);
2) Transfer of text after overflow/underflow (mostly editeng, with
view-related aspects such as cursor motion in svx/svdraw);
3) Activation of triggers for overflow detection and text transfer (mostly
SdrObjEditView and OutlinerView, resp. svx/svdraw and editeng. One line was
changed in sd);
4) Definition of UNO properties and their loading code from files (by
attribute: "draw:chain-next-name" that defines Chainable boxes).

What may/will be affected
---
NOTE: The vast majority of the code above should only affect  LO behavior
for docs that have the tag in (4) set to something sensible.

Some things may be broken only for chainable boxes (I wonder about the
effects of (1b) for instance).

However, there are some changes that modify behavior for both Chainable and
non-Chainable boxes, in particular, bullet (3) above.
For this, I would look in particular at the commits in the attached file.

Cheers,
Matteo
commit 54b576c3b3bf3d67c5ffd4ae391f6c03e3647dc1
Author: matteocam 
Date:   Mon Sep 7 20:01:35 2015 +0200

Handle chaining for cutting and pasting

Change-Id: Iec08e339a7f06c5fa56e67b42206b31c766f845b

commit 731000696b282f457a7e003297d4f158849825d4
Author: matteocam 
Date:   Mon Sep 7 19:58:16 2015 +0200

Handle DEL key for chaining

Change-Id: I124b1adf6df3c42a58d45eaeb0e1e053c0eea4c9

commit 1a86da45320faf5f644c1a82c07bd9b522a2a351
Author: matteocam 
Date:   Mon Sep 7 16:37:56 2015 +0200

Enable chaining after a key is pressed

Change-Id: I64351619dd0886f3bb0c080557864c46a17d737d

commit 3748019d58154b2851999c3ea9f2ab223c8e3bc3
Author: matteocam 
Date:   Mon Sep 7 12:44:37 2015 +0200

Change EndTextEdit behavior to support recursive overflow

Change-Id: I14009fa2e91b19a850e45484de7cd234e872689a


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 11

[Matteo Campanelli]

Hi there,
last week had no real breakthroughs in terms of features.
What went on:

- Submitted code to gerrit for review
- Done a few experiments on undo-ing SetText operations
- Rewritten code for removing overflowing text in terms of
Outliner::QuickDelete instead of the previous (and more cumbersome)
Outliner::SetText.
- Made domino chaining 'mostly' working (it does not work in one case).
- Fixed a few bugs on code on chain structure.

There are a few features that are implemented but showing misbehavior,
namely:
- the rewriting in terms of QuickDelete has a couple corner cases that
don't work yet.
- domino chaining crashes.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Failing using logerrit testfeature - ERROR: missing Change-Id in commit message footer

[Matteo Campanelli]

I'm trying to use logerrit testfeature as Thorsten suggested here
http://lists.freedesktop.org/archives/libreoffice/2015-July/069519.html.
Unfortunately I get the error below at some point.
I tried to install the hook suggested but I get the same error (what I did
was: I modified the logerrit script to launch the suggested scp command
right before making the commit).

Any suggestions?

Matteo

remote: Processing changes: refs: 1, done
remote: *ERROR: missing Change-Id in commit message footer*
remote: Suggestion for commit message:
remote: noop commit: trigger test build for branch
feature/gsoc14-draw-chained-text-boxes
remote:
remote: branch is at:
remote: commit 116aff4b41e0ef501f1998a14789626fe09820bb
remote: Author: matteocam matteo.campane...@gmail.com
remote: Date:   Sat Aug 1 00:50:13 2015 +0200
remote:
remote: Minor fix
remote:
remote: XX: If5bc6647ce07cbe7e6f324c2081168238f9c258d
remote:
remote: Change-Id: I3860b9bbd2fb808f6eff7c9956de32b00f917b55
remote:
remote: Hint: To automatically insert Change-Id, install the hook:
remote:   gitdir=$(git rev-parse --git-dir); scp -p -P 29418
matteo...@gerrit.libreoffice.org:hooks/commit-msg ${gitdir}/hooks/
remote:
remote:
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 10

[Matteo Campanelli]

Hi everybody,
from last week:
- cutting text triggers underflow
- we can read the structure of a text chain from file
- code was cleaned in various places (e.g. now some resizing necessary
for overflow check occur only if we have a chainable box)
- rebased on top of current master
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC15] Chained Text Boxes - Report Week 9

[Matteo Campanelli]

On Thu, Jul 30, 2015 at 12:12 AM Thorsten Behrens 
t...@documentfoundation.org wrote

 Yep, except for the pushing part - we really want to run this past
 gerrit CI first. ;)

Just finished the rebase master process.
Could you please confirm me that the next steps are:
- pushing this new history on feature/gsoc14-draw-chained-text-boxes
- ./logerrit submit master [from the
feature/gsoc14-draw-chained-text-boxes branch]


Matteo



 Cheers,

 -- Thorsten

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Text Chains in Draw] A few question on general handling of chains of text boxes

[Matteo Campanelli]

This part has been completed; also we can chain-links are set directly
after loading from file now.
Thorsten, everything that worked already is working after setting the UNO
property but the solution is a bit dirty. Please see my last chat message
today.

Matteo


On Fri, Jul 24, 2015 at 12:14 AM Thorsten Behrens 
t...@documentfoundation.org wrote:

 Matteo Campanelli wrote:
  *Question*: what is a good place to keep these chains in svx?
  They hold some kind of global information so my first guess would be
  SdrModel. Does that make sense?
 
 Absolutely.

  At some point it should be possible to specify next links from the UI.
  *Question*: where should one put such commands/methods (called from the
 UI)
  for setting/removing links ? SdrTextObj-s themselves?
 
 There, or as a binary op on the SdrModel again, with the two boxes
 (upstream  downstream) as parameters. See what feels more natural
 when calling it (SdrTextObj::setNextLink() or SdrModel::linkBoxes(up,
 down))...

 HTH,

 -- Thorsten

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC15] Chained Text Boxes - Report Week 9

[Matteo Campanelli]

Hi Thorsten,

On Mon, Jul 27, 2015 at 1:58 PM, Thorsten Behrens 
t...@documentfoundation.org wrote:


 Hi Matteo,

 nice progress there again! As said earlier, let's now start getting
 bits and pieces of that into master. Depending on your risk profile,
 as an experimental feature, or w/o UI but enabled by default. ;)


I'm sorry for the basic question but the next step for this is basically
pulling master+rebasing+pushing to master?

Matteo


 Cheers,

 -- Thorsten

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 9

[Matteo Campanelli]

Progress from last week:
- Overflow handling is triggered after pasting again  (and cursor motion is
handled too);
- Left arrow, Backspace and Del key inputs are handled;
- Refactoring of cursor motion code.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Text Chains in Draw] A few question on general handling of chains of text boxes

[Matteo Campanelli]

Hi,

I am working on the global handling of chains of text boxes in Draw.
The idea would be to keep the information on which text objects belong to
which chain by using a svx class TextChain (that I created).
An example of a (partial) interface TextChain would be the following (quite
similar to a linked list):
[Side reminder: text boxes roughly correspond to SdrTextObj objects].
- InsertNode(SdrTextObj *prev, SdrTextObj *newNode)
- AppendNode(SdrTextObj *newNode)
- GetPrevNode(SdrTextObj *)
- GetNextNode(SdrTextObj *)

Also note that in a Draw document there can be an arbitrary number of
chains of SdrTextObj-s.

*Question*: what is a good place to keep these chains in svx?
They hold some kind of global information so my first guess would be
SdrModel. Does that make sense?

At some point it should be possible to specify next links from the UI.
*Question*: where should one put such commands/methods (called from the UI)
for setting/removing links ? SdrTextObj-s themselves?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 8

[Matteo Campanelli]

Hi,

some progress from this week:
- cursor motion works properly (forward)
- cursor motion works even if arrow keys are used (it's not tied any more
to editing only)
- several smaller issues have been fixed.

Next goals:
- Have pasting working (again)
- Start thinking of merging to master
- Having a decent interface for cursor motion.

Cheers,
M.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 7

[Matteo Campanelli]

Hi,

Last week focus was on cursor motion and fixing some odd behavior.
What we got is that cursor can move from one box to another after an
Overflow and most of the code for positioning correctly exists.

What does not work and/or should be done next:
- the odd behavior I mentioned above is probably due, or at least includes,
the mysterious creation of empty paragraphs by the dozens after text
transfer. This is still an open issue.
- cursor transfer for pasting has not been handled yet.
- after transferring to the next box we are repositioned to the beginning
of the box after setting it to the right index.
- Backspace and arrow keys should be handled for cursor motion too.

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 6

[Matteo Campanelli]

Hi,
this week we made progress on saving text format while transferring text.
Now we have the expected behavior. Still there are a few issues arising in
editing mode.

Even more importantly the code was rebased on master and modified
accordingly.

I developed some ideas on how to have some reasonable cursor motion
behavior in linked text boxes and I'm going to try them out this week.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text in Draw - A screencast of current prototype

[Matteo Campanelli]

Short blog post and link to Youtube video here:
http://gsoc15-draw.logdown.com/posts/283339-text-chaining-in-draw-results-at-midterm

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 5

[Matteo Campanelli]

Hi there,
from this week:
- implemented underflow handling
- created appropriate classes reducing SdrTextObj's responsibility and
separating editing vs non-editing behavior

Next steps are:
- having a look at why some automatic tests in sd fail (a clue is that
current overflow/underflow testing code has reverted some ad hoc fixes that
set paper size at specific values. So I should probably look at this commit
http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/gsoc14-draw-chained-text-boxesid=f907f74a5ef3372f275c2ef5cb51d38823383e34
)
- implementing cursor motion though a chain of boxes and keeping style
sheets consistent

M.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC15] Chained Text Boxes - Report Week 5

[Matteo Campanelli]

On Mon, Jun 29, 2015 at 3:06 PM, Thorsten Behrens 
t...@documentfoundation.org wrote:



 that starts to look really nice! How about some short screencast, or

I agree it's about time. Should get some post done by this week then.

at least a few screenshots about the progress  a blog update? ;)

 Well done there, cheers,

 -- Thorsten

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 4

[Matteo Campanelli]

Hi there,
progress from this week revolved around:
- Refactoring overflowing code so to use an object having global
information on text chain;
- Implementing underflow handling during editing mode.

Underflow exploits overflow under the hood; current implementation is
basically a finite state machine that goes from underflow to overflow to
underflow again.

In some situations underflow handling behaves correctly but in others it
dies silently (for example after adding a character that keeps underflow
status).

Next step is looking into the issue above and deal with underflow while
drawing static text.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - A plan of next milestones

[Matteo Campanelli]

Hi there,
I was thinking of the next important goals for something that can be
(hopefully) merged in master at the end of the Summer and I thought of
sharing publicly my plan.
The estimated times are kinda pessimistic since it is likely I missed some
important.

- Get Underflow working as well as overflow (1-2 weeks)
- Have cursor motion work automatically among chained boxes (1 week)
- Have undo working (1 week)
- Have style sheets preserved and allow # of boxes  2. (2 weeks)

In the worst case this should keep me busy until around 19th of July.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Report Week 3

[Matteo Campanelli]

Hi,
this week there were a lot of changes in code architecture.
Overflow handling now is now similar to how AutoFit works:
- a specific handler is triggered in ImpEditEng::FormatDoc if overflow
occurs during editing
- otherwise an appropriate drawinglayer primitive takes care of everything

As a consequence now overflowing is handled even during resizing.
Problems with special cases, such as overflowing text in clones during
resizing, have been treated appropriately with small non-too-hacky-looking
portions of code.

Next direction 1: one more sub-feature
-
For now only shrinking and overflow cause movements of text. The next step
is to let text flow back into a previous link if enough space appears.
If we dealt with overflow so far, next step is dealing with underflow.

Next direction 2: issue fixing
-
There is a current occasional issue where non-overflowing text is copied in
the destination box (instead of the overflowing one).
To reproduce:
- Have two boxes whose name start with Chainable (necessary to make them
act as a chain atm);
- Set the first box's text to A random line making sure to have enough
space for it so that it fits on one line.
- Shrink the first box from below so that only that one line fits (don't
cause overflow yet)
- Shrink the first box from the right edge so to cut the word line.

Expected behavior: line should be prepended to the second box; first box
should contain only A random.

Observed behavior: second box get A random prepended; First box is empty.

Next direction 3: fixing hacks
---
Currently transfer of text in decomposition of static text is done by
calling a special Outliner (a chaining outliner) from SdrModel. Besides
being a quite ugly solution (a SdrModel has a new outliner adhoc for this
specific feature) it would probably break when transfer of text occurs
recursively in a chain of three of more boxes.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC15] Chained Text Boxes - Week 2 Report

[Matteo Campanelli]

On Sat, Jun 6, 2015 at 5:39 PM, Thorsten Behrens t...@documentfoundation.org
 wrote:


 That should generally not need any special handling - it's also the
 DrawOutliner being called to re-flow text. Same BTW for loading a
 document - initial layout there also happens via Outliner.


Right.
The current problem in fact is that most of the text transferring code is
now invoked by SdrTextObj::onEditOutlinerStatusEvent, which is called only
when we have an editing outliner.
So the idea should be to make that code independent of these editing
events, which should be feasible as you said above. :-)

Matteo


 Cheers,

 -- Thorsten

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Week 2 Report

[Matteo Campanelli]

Hi,

This week we made it able to cut non-overflowing paragraph and move them to
the right place.

Also a couple problems were found:
- Style sheets are lost on the way when transferring text after overflow.
- Resizing a box does not trigger text transfer when overflow occurs.

The causes of the two seems respectively:
- style sheets are never set while creating the new text objects to be
moved around. So the solution should be simple enough.
- since editing is not activated while resizing, the usual callbacks
invoked after we find overflow are simply not activated. One way to deal
with this woud be to keep always active some editing-independent callback
or at least to activate it temporarily from
SdrTextObj;;NbcAdjustTextFrameAndHeight (called at resizing).

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On styles lost during overflowing text transfer - warnings of Draw

[Matteo Campanelli]

Hi there,

as I mentioned in the past, the current implementation seems to lose styles
here and there when transferring text.
Could this be related to some warnings I'm getting during the execution of
Draw? If not what are these anyway?
Here I'm pasting some:

warn:legacy.osl:13760:1:svl/source/items/style.cxx:458: Incorrect index
warn:legacy.osl:13760:1:xmloff/source/core/xmlerror.cxx:184: An error or a
warning has occurred during XML import/export!
Error-Id: 0x10040004
Flags: 1 WARNING
Class: 4 API
Number: 4
Parameters:
Exception-Message:
Position:
Public Identifier: [FILENAME]
System Identifier: [FILENAME]
Row, Column: 231,1


warn:legacy.osl:13760:1:svl/source/undo/undo.cxx:487:
SfxUndoManager::ClearRedo: suspicious call - do you really wish to clear
the current level?

warn:basic.sbx:13760:1:basic/source/sbx/sbxvar.cxx:423: dangling:
[@SBRTL].SetParent([StarBASIC])
warn:basic.sbx:13760:1:basic/source/sbx/sbxvar.cxx:423: dangling:
[StarBASIC].SetParent([Standard])

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: On styles lost during overflowing text transfer - warnings of Draw

[Matteo Campanelli]

On Fri, Jun 5, 2015 at 8:09 AM, Thorsten Behrens t...@documentfoundation.org
 wrote:

 Sounds a bit like. At least I'm not able to trigger those in an
 unmodified master build (assuming it's rather normal text typing /
 undo pressing you were doing there).

Confirmed. Same file that gave me those warnings does not give them on an
unmodified master.

M.


 Cheers,

 -- Thorsten

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chained Text Boxes - Week 1 Report

[Matteo Campanelli]

Hi there,

We got:
1) being able to capture live overflowing paragraphs and copy them  in the
next link box
2) first experiments with moving text inside paragraphs: we are able to
prepend arbitrary strings live before overflowing text. This is a first
step towards breaking the overflowing paragraphs in an arbitrary point.

Next steps:
- proceeding with point 2 and let the the new overflowing text being
prepended.
- reformulate a plan: Thorsten and I talked about the possibility that what
Writer does might not be simply (read feasibly) reproducible here in
Draw. I should figure what seems feasible and what not given what I learnt
this week..

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Error building LO - strlen was not declared in this scope on fresh Ubuntu 15.04 install

[Matteo Campanelli]

Jagobo Aragunde wrote:


 Since you mention that adding the proper #include did not work and this
 is a fresh Ubuntu install, I wonder if the package providing string.h is
 missing. Check the presence of libc6-dev.


Apparently libc6-dev was installed. Still in the same situation.
Thanks though :)

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC15] Chaining text boxes in Draw - more brainstorming on specifications and RSS

[Matteo Campanelli]

Hi there,
another blog post on the topic:
http://gsoc15-draw.logdown.com/posts/276831-text-chaining-in-draw-an-attempt-to-specifications

To avoid more spam on the mailing list, here is the RSS for the blog, I
will avoid posting it here from now on:
http://gsoc15-draw.logdown.com/posts.atom

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Error building LO - strlen was not declared in this scope on fresh Ubuntu 15.04 install

[Matteo Campanelli]

Hi there,
after
 several minutes of compilation I got the following error(s). Any ideas?
[Manual dirty solutions like insert the related #include macros did not
work]

// beginning error message from make
[SOMEPATH]/include/rtl/ustring.hxx:188:27: error: ‘strlen’ was not declared
in this scope
In file included from [SOMEPATH]/include/xmlreader/pad.hxx:27:0,
 from [SOMEPATH]/include/xmlreader/xmlreader.hxx:35,
 from [SOMEPATH]/include/vcl/builder.hxx:19,
 from [SOMEPATH]/include/vcl/dialog.hxx:25,
 from [SOMEPATH]/editeng/source/editeng/editdbg.cxx:22:
[SOMEPATH]/include/rtl/strbuf.hxx: In instantiation of ‘typename
rtl::internal::ConstCharArrayDetectorT, rtl::OStringBuffer::Type
rtl::OStringBuffer::append(T) [with T = const char [12]; typename
rtl::internal::ConstCharArrayDetectorT, rtl::OStringBuffer::Type =
rtl::OStringBuffer]’:
[SOMEPATH]/editeng/source/editeng/editdbg.cxx:70:41:   required from here
[SOMEPATH]/include/rtl/strbuf.hxx:477:27: error: ‘strlen’ was not declared
in this scope
 assert( strlen( literal ) == internal::ConstCharArrayDetector T
::size - 1 );

// end errors

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Error building LO - (LIBO_UDK 4.4 not found)

[Matteo Campanelli]

Hi there,

I was building LO on GNU/Linux (on a machine where LO building went smooth
until a couple months ago) and I got this message [SOMEPATH is my
replacement of a longer path]:

DynamicLibraryManagerException: Failed to load dynamic library:
SOMEPATH/libreoffice/workdir/LinkTarget/CppunitTest/libtest_sax.so
SOMEPATH/libreoffice/instdir/ure/lib/libuno_cppu.so.3: version
`LIBO_UDK_4.4' not found (required by
SOMEPATH/libreoffice/instdir/program/libuno_cppuhelpergcc3.so.3)

Path is
'.:SOMEPATH/libreoffice/solenv/bin:/home/seriouspillow/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-7-openjdk-amd64/bin'
[build LNK] CppunitTest/libtest_sot_test_sot.so

Error: a unit test failed, please do one of:

export DEBUGCPPUNIT=TRUE# for exception catching
export CPPUNITTRACE=gdb --args# for interactive debugging on Linux
export CPPUNITTRACE=\[full path to devenv.exe]\ /debugexe # for
interactive debugging in Visual Studio
export VALGRIND=memcheck# for memory checking

and retry using: make CppunitTest_sax

make[1]: *** [SOMEPATH/libreoffice/workdir/CppunitTest/sax.test] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [build] Error 2

Any ideas?

_Maybe_ it's noteworthy that I'm trying to compile a branch whose last
commit is around 9 months old; just mentioning that for completeness.

I tried using EXPORT DEBUGCPPUNIT=TRUE and make CppunitTest_sax but it
produced no output after [build CUT] sax for around 30 minutes.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Error building LO - (LIBO_UDK 4.4 not found)

[Matteo Campanelli]

All solved. Sorry for the noise.
It was loosely related with ccache and using ccache -C did it.

Matteo

On Sat, May 16, 2015 at 11:14 AM, Matteo Campanelli 
matteo.campane...@gmail.com wrote:

 Hi there,

 I was building LO on GNU/Linux (on a machine where LO building went smooth
 until a couple months ago) and I got this message [SOMEPATH is my
 replacement of a longer path]:

 DynamicLibraryManagerException: Failed to load dynamic library:
 SOMEPATH/libreoffice/workdir/LinkTarget/CppunitTest/libtest_sax.so
 SOMEPATH/libreoffice/instdir/ure/lib/libuno_cppu.so.3: version
 `LIBO_UDK_4.4' not found (required by
 SOMEPATH/libreoffice/instdir/program/libuno_cppuhelpergcc3.so.3)

 Path is
 '.:SOMEPATH/libreoffice/solenv/bin:/home/seriouspillow/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-7-openjdk-amd64/bin'
 [build LNK] CppunitTest/libtest_sot_test_sot.so

 Error: a unit test failed, please do one of:

 export DEBUGCPPUNIT=TRUE# for exception catching
 export CPPUNITTRACE=gdb --args# for interactive debugging on Linux
 export CPPUNITTRACE=\[full path to devenv.exe]\ /debugexe # for
 interactive debugging in Visual Studio
 export VALGRIND=memcheck# for memory checking

 and retry using: make CppunitTest_sax

 make[1]: *** [SOMEPATH/libreoffice/workdir/CppunitTest/sax.test] Error 1
 make[1]: *** Waiting for unfinished jobs
 make: *** [build] Error 2

 Any ideas?

 _Maybe_ it's noteworthy that I'm trying to compile a branch whose last
 commit is around 9 months old; just mentioning that for completeness.

 I tried using EXPORT DEBUGCPPUNIT=TRUE and make CppunitTest_sax but it
 produced no output after [build CUT] sax for around 30 minutes.

 Cheers,
 Matteo

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC '15] Chained Text Boxes in Draw - a positional post

[Matteo Campanelli]

Hi everybody,
here is a short, informal-but-with-a-technical-eye description of last
year's prototype and some immediate directions  and questions.
http://gsoc15-draw.logdown.com/posts/275773-a-prototype-for-dynamic-text-flow

Let me know if you have feedback on the (implicit) questions at the end of
the post - or on any other aspect of the project.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC 2015 - Dynamic Text Chaining in Draw] (Re-)Introductions

[Matteo Campanelli]

Hi all,
TL;DR: just wanted to say hi :) ; I'm working on a continuation of a
project on Draw from last year; some parts of the project will be messy and
in the next days I'll contact this mailing list for further help.

I'm Matteo and I've recently been accepted at GSoC 2015 to work on text
features in Draw. In my work, Thorsten Behrens and Fridrich Strba will be
my official mentors and will take (I'm sure) good hackery care of me and
the project.
For those of you who hung around the GSoC conversation last Summer, yes,
this project is a follow up on a prototype developed last year.

If anyone were interested, my proposal for this Summer can be found here
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/matteocam/5700735861784576
and
here
https://matteocam.github.io/output/announcing-chained-text-in-draw-a-prototype-implementation.html
is a short post on the current prototype (note however that there was
fortunately some progress since and some details of the post are somewhat
outdated).
In a nutshell, this year I plan to completely implement dynamic text
overflowing among Draw's text boxes and add hyphenation features. The first
task turned out  to be quite a challenge last year and still requires  much
more work. The first part of the summer will be dedicated to finish that.

The goal for this week is to dive into old code and get a technical sense
of the main current issues, then ask for specific help and ideas on them.
An informal description of the situation is that now: 1) text can be moved
only as paragraphs (whereas it should be broken in arbitrary pieces), 2)
there is no edit-mode code for chaining, everything happens after user
edited, 3) my current code is not merge-able to master yet  (in particolar
it breaks  an older patch to fix #i119885# and yields some occasional, hard
to replicate SIGABRT-s).
Since I failed last year in this respect, I am also planning to start a
blog _now_ about technical aspects of the work, so that it is easier for
anyone who wanted to jump in (now and later) to have both a global as well
as awareness of details of the project and I can reference to that in my
posts on the list.

That said, it is great to be back on the LibreOffice ship.
Happy hacking, everybody.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC '15 Ideas] Finishing up on enhanced text boxes in Draw?

[Matteo Campanelli]

Hi all,
last summer I worked on this project
https://wiki.documentfoundation.org/Development/GSoC/Successfully_Implemented_Ideas#Improve_Text_Boxes_in_Draw
for GSoC '14. Part of it was completely implemented, part was not. In
particular, the results for overflowing-text dynamics are still too much
of a work in progress (for a quick intro to the task and a (somewhat
accurate) summary of the current situation, see here
https://matteocam.github.io/output/announcing-chained-text-in-draw-a-prototype-implementation.html
).

It would be great to finish that task and I would like to know whether you
guys think it can make a sensible proposal for GSoC '15.

If the question is Is there enough work left to be done to fill a whole
summer?.
Maybe not, but my feeling is that there is plenty of work to fill at least
half of it. The rest of the time might be spent working on a neglected part
of last year's proposal: hyphenation in Draw.

Looking forward to comments.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Bug 88457: urls fails to copypaste in Calc - Asking for directions and code pointers

[Matteo Campanelli]

Hi all,
I was looking at this recent bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=88457redirected_from=fdo

The bug's behavior is basically: urls from a cell cannot be copied and
pasted in another cell in Calc. IOW nothing happens after pasting (however
special paste seems to work).

It seems the bug was introduced with one of my commits last Summer, namely:
http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/gsoc14-draw-text-background-colorid=c2580813426a58cd2ab22efacec9d28423201562

This small commit simply registers a new text item, EE_CHAR_BKGCOLOR, to
deal with the background color of text.
Does anyone have a guess of how this could affect this behavior on Calc?

It seems that urls in Calc are automatically filled with a grey background,
so I wonder whether this conflicts with the handling of background color by
EE_CHAR_BKGCOLOR.
Does anyone have some pointers to where this happens in Calc's code (i.e.
where urls are assigned a background)?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Chained Text Boxes - Cleaning up code before incorporation to master - Are we okay with changes to #i119885#?

[Matteo Campanelli]

What I did:
- make check
- make slowcheck
- make subsequentcheck
So far, so good.
Do such commands already run tests?

Then I tried to see what the description of the code I removed was and to
play with Draw in case I saw anything suspicious (the change is in svx, are
Impress and Draw the only possible damaged spots?).
From a comment:
#i119885# Do not limit/force height to geometrical frame (vice versa for
vertical writing)
Link to the issue in the bugtracking:
https://issues.apache.org/ooo/show_bug.cgi?id=119885

And there is something not quite working: when Fit to height is off for a
box then you cannot see any overflowing text while editing.
Next step is seeing if this is caused by some other parts of my code or by
that specific change.

Matteo


On Mon, Sep 22, 2014 at 1:30 AM, Thorsten Behrens 
t...@documentfoundation.org wrote:

 mmh - so nope, I'm afraid that will likely break things in master, so
 I'd prefer if we fix that in the branch. First thing to do is to run
 all tests (including make slowcheck and make subsequentcheck). If you
 played with all applications, and are reasonably certain no observable
 behaviour changed, of course we can merge that (after giving some
 advance warning here on the dev and QA list).

 And thanks for digging into this again!

 Cheers,

 -- Thorsten

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Chained Text Boxes - Cleaning up code before incorporation to master - Are we okay with changes to #i119885#?

[Matteo Campanelli]

Thorsten,
remember when we decided to remove several lines of the type Size
aMaxSize(10,10), nWdt = 100...
because they interfered with checking that a page overflow occurred?
(I'm referring to the changes in this commit
http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/gsoc14-draw-chained-text-boxesid=f907f74a5ef3372f275c2ef5cb51d38823383e34
in particular.)

If not, never mind, but I'm mentioning that because then I basically
reverted changes related  to the issue in the subject - and I don't know if
everything works now.
Shall I just leave stuff as it is and once incorporated in master we'll
find out what happens?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Chaining overflowing text between boxes does not work when all text overflows

[Matteo Campanelli]

On Fri, Aug 8, 2014 at 6:18 PM, Matteo Campanelli 
matteo.campane...@gmail.com wrote:


 [Code]

The code above truncates the text in the first box.
 The text in the second paragraph is restored by creating an appropriate
 SdrChainedTextPrimitive object and its create2DDecomposition method.
 It seems that such a method is never called when all text is overflowing,
 i.e. when newText above is NULL.
 The two are plausibly one consequence of the other.

Elaborating on the last two sentences:
I verified that when OutlinerParaObject is NULL, SdrChainedTextPrimitive is
not created (and thus text cannot be moved to the second text box).

I traced the problem back to SdrTextAttribute objects in
createTextPrimitive not having a property isToBeChained set to true.
Apparently, this happens because createSdrFooAttribute functions
(sdrattributecreator.cxx) ignores chaining property. I fixed the issue for
createSdrTextAttribute but it seems not to be that simple for the sibling
methods.
Working on that...


 An ideal solution would be to replace that NULL pointer with a dummy
 OutlinerParaObject or something like that.
 Any hint on how to do this?

This may still be necessary to bypass the problem.


 In case anyone wanted to have a look:

 http://cgit.freedesktop.org/libreoffice/core/tree/svx/source/svdraw/svdotxed.cxx?h=feature/gsoc14-draw-chained-text-boxes#n252


 http://cgit.freedesktop.org/libreoffice/core/tree/svx/source/sdr/primitive2d/sdrtextprimitive2d.cxx?h=feature/gsoc14-draw-chained-text-boxes#n488

 Cheers,
 Matteo

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Created Wiki page on code for Chained Text Boxes in Draw -- still in stub-phase

[Matteo Campanelli]

https://wiki.documentfoundation.org/Features/ChainedTextBoxesDraw

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Chaining overflowing text between boxes does not work when all text overflows

[Matteo Campanelli]

I have an issue with my current chaining code.
The current chaining mechanism seems to be working:
once out of edit mode, when a page overflow occurs, the first paragraph
that causes it and all the next ones are moved in the next link in the
chain .
The problem arises when the first paragraph is the one that overflows
already.
Instead of disappearing from the first text box and appearing into the the
second one, it rather simply disappears from the first.

I have an hypothesis about what goes wrong.
The following code describes what happens when we get out of edit mode:

// the following is pseudo code
SdrTextObj::EndTextEdit(...) {
[...]
  // ignores overflowing text
  newText = Non_Overflowing_Paragraphs() // !! It is NULL if all text
overflows
  // saves overflowing text for later use from other SdrTextObj-s in the
chain
  this-overflowingText = Overflowing_Paragraphs()

  // set truncated text in current SdrTextObj
  this-SetCurrentText(newText) // this method is SetOutlinerParaObject in
the original code

[...]
}

The code above truncates the text in the first box.
The text in the second paragraph is restored by creating an appropriate
SdrChainedTextPrimitive object and its create2DDecomposition method.
It seems that such a method is never called when all text is overflowing,
i.e. when newText above is NULL.
The two are plausibly one consequence of the other.

An ideal solution would be to replace that NULL pointer with a dummy
OutlinerParaObject or something like that.
Any hint on how to do this?

In case anyone wanted to have a look:
http://cgit.freedesktop.org/libreoffice/core/tree/svx/source/svdraw/svdotxed.cxx?h=feature/gsoc14-draw-chained-text-boxes#n252

http://cgit.freedesktop.org/libreoffice/core/tree/svx/source/sdr/primitive2d/sdrtextprimitive2d.cxx?h=feature/gsoc14-draw-chained-text-boxes#n488

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Chained Text Boxes in Draw - Report 03/08/2014

[Matteo Campanelli]

Hi all,
last week's work saw progress quite close to the final goal:
I was able to deal with overflowing texts in boxes by actually sending
only the overflowing paragraph in the next links.
There seems to be some misbehavior at the moment though (e.g.
sometimes some paragraphs disappear not showing neither the source box
nor in the recipient one).

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Chained Text Boxes in Draw - Report 28/08/2014

[Matteo Campanelli]

Hi all,
from last week there is some encouraging progress:
- I implemented a suitable primitive2d class in svx/ for text needing to be
chained;
- when a page overflow occurs, the status need to be chained is set and
text from one box is copied in another by creating the appropriate text
primitive (text is still not truncated though).

An immediate next action is to  make the possibility of dealing with chains
that have more than two text boxes.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

On extending SdrTextPrimitive2D

[Matteo Campanelli]

In one of my latest commits
http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/gsoc14-draw-chained-text-boxesid=be897ed79d331276e8d686ac35956cdd57e24615
I
created a class that extends SdrTextPrimitive2D.
The derived class - SdrChainedTextPrimitive2D - should be used for dealing
with text in chained text boxes.

I have a couple concerns about the overriding of two virtual methods:
1) SdrChainedTextPrimitive2D::create2DDecomposition should return a
Primitive2DSequence. What is this for?
Currently I'm returning an empty sequence on which I apply the following
mysterious method other similar classes are using:
encapsulateWithTextHierarchyBlockPrimitive2D(aEmptySequence)

2) SdrChainedTextPrimitive2D::createTransformedClone, I have no idea what
this is for.
My temporary solution was puttin an assert(0) in it, so far it seems its'
never been called.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Chained Text Boxes in Draw - Report 21/07/2014

[Matteo Campanelli]

Hi!
Last week I managed to have a working skeleton of the model presented in my
last report
http://lists.freedesktop.org/archives/libreoffice/2014-July/062289.html,
plus several important thorny subgoals were accomplished, i.e. latest code
can:
- identify an overflow of text in a box
- refer to specific text boxes when a change occurs
- copy text from one text box to another (this is relevant because chaining
text requires sending the overflowing text)

Remaining subgoals (in descending order of priority):
- implement text 2d primitive for chained text
- propagate the specific position where overflow occurs (rather than a
generic HasOverflowOccurred? boolean)
- Let only the overflowing text be copied
- implement a way to access Text Boxes by name (besides indexes)

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Chained Text Boxes in Draw - Report 13/07/2014

[Matteo Campanelli]

Hi all,
on last week:
- managed to truncate arbitrary portion of text in a box;
- formulated a general model of what the flow should look like:

a) editeng (ImpEditEngine::FormatDoc?) realizes there is an overflow in
text box with a successor;
b) [still editeng] the overflowing point in the overflowing text portion
 (possibly empty) is marked;
c) [svx] the first part of the overflowing portion is rendered, the rest of
it is sent to the successor text box in the chain. Both this second part of
the first overflowing portion as well as all the remaining following
overflowing portions are sent back to editeng for new layouting.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Copying content from one text box to another in svx/ - A failed attempt

[Matteo Campanelli]

Today I tried to embed some code to link the content of one text box to
another in Draw. I took heavy inspiration from some existing code in
SdrTextObj::FitFrameToTextSize()
http://docs.libreoffice.org/svx/html/svdotext_8cxx_source.html#l00205.
However I get a SIGSEGV in some other part of the code shortly afterwards.

What I tried to do was the following:
- Having two text boxes in the document,
- I tried to copy (a part of) the content from SdrPage::GetObj(0) into
SdrPage::GetObj(1). This occurs in svx's drawinglayer and in particular
in impTextBreakupHandler.
- The text is copied into the outliner of the second text box to be
layouted again (simulating what FitFrameToTextSize above does. An important
difference with that code is that now two different boxes are used).

This is the link to the main commit:
http://cgit.freedesktop.org/libreoffice/core/commit/?h=feature/gsoc14-draw-chained-text-boxesid=643d9cf5e73e523c88d1b545dd27d98feb1bf088


Here is the seg. fault message:
Program received signal SIGSEGV, Segmentation fault.
0x7f5cb26d9b5c in ContentAttribs::GetItem (this=0x99a1,
nWhich=4006)
at
/home/seriouspillow/Proiects/libreoffice/gsoc/core/editeng/source/editeng/editdoc.cxx:1804
1804if ( pStyle  ( aAttribSet.GetItemState( nWhich, false ) !=
SFX_ITEM_ON  ) )


Thorsten, any opinions?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Copying content from one text box to another in svx/ - A failed attempt

[Matteo Campanelli]

On Mon, Jul 14, 2014 at 5:56 PM, Terrence Enger ten...@iseries-guru.com
wrote:


 The long string of nines looks like the result of reading freed memory
 in a debug build.  valgrind may be able to tell you where the memory
 was freed, if you have the patience to wait for it.


Valgrind definitely found something kinda directly related to my new code;
still have to understand what goes wrong at the lowermost call though. Some
relevant output:

*==19443== Invalid read of size 8*
==19443==at 0xF4339F6: *SdrTextObj::ImpGetDrawOutliner()* const
(svdotext.cxx:1233)
==19443==by 0xF43988B: SdrTextObj::impCopyTextInTextObj(SdrTextObj*)
const (svdotextdecomposition.cxx:813)
==19443==by 0xF4389BF: (anonymous
namespace)::impTextBreakupHandler::impHandleTruncatedPortion(DrawPortionInfo
const) (svdotextdecomposition.cxx:587)
==19443==by 0xF4387EE: (anonymous
namespace)::impTextBreakupHandler::impHandleDrawPortionInfo(DrawPortionInfo
const) (svdotextdecomposition.cxx:529)
[more backtrace...]
*==19443==  Address 0xd8 is not stack'd, malloc'd or (recently) free'd*
==19443==
==19443==
*==19443== Process terminating with default action of signal 11 (SIGSEGV)*
==19443==  Access not within mapped region at address 0xD8
==19443==at 0xF4339F6: SdrTextObj::ImpGetDrawOutliner() const
(svdotext.cxx:1233)
==19443==by 0xF43988B: SdrTextObj::impCopyTextInTextObj(SdrTextObj*)
const (svdotextdecomposition.cxx:813)
[more backtrace...]

Is 0xd8 the address returned by the lowermost call by any chance
(i.e. SdrTextObj::ImpGetDrawOutliner())?

Matteo


 HTH,
 Terry.



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] Text Background Color in Draw - Report 22/06/2014

[Matteo Campanelli]

This patch is for fixing the crash and generate an inadmissible data type
dialog.

Thorsten, I checked again and it seems to me that the code now follows
CharUnderlineColor everywhere.
But I have no idea about the other name CharUnderlineColor is mapped to.



On Thu, Jul 10, 2014 at 2:20 PM, Miklos Vajna vmik...@collabora.co.uk
wrote:

 Hi Matteo,

 I noticed a crash that's probably related to your (otherwise great :-)
 ), text background editeng work -- care to take a look?

 1) Start Writer, enable form controls toolbar (View - Toolbars - Form
 controls)
 2) Click the more controls button, pick the Date Field
 3) Draw a rectangle in the body text area to create an instance
 4) Try to query its background color via UNO: Tools - Macros -
 Organize macros - Basic - Edit, then type:

 print ThisComponent.DrawPage(0).CharBackColor

 and Press F5 to run, it crashes with:

 Program received signal SIGSEGV, Segmentation fault.
 0x73b4d9fc in SfxItemSet::Get (this=0x1dfaa00, nWhich=0,
 bSrchInParent=true) at
 /home/vmiklos/git/libreoffice/master/svl/source/items/itemset.cxx:1002
 1002DBG_ASSERT( !pItem-ISA(SfxSetItem) ||
 (gdb) bt 10
 #0  0x73b4d9fc in SfxItemSet::Get (this=0x1dfaa00, nWhich=0,
 bSrchInParent=true) at
 /home/vmiklos/git/libreoffice/master/svl/source/items/itemset.cxx:1002
 #1  0x7fffd2cc9de6 in SdrObject::GetMergedItem (this=0x226b140,
 nWhich=0) at
 /home/vmiklos/git/libreoffice/master/svx/source/svdraw/svdobj.cxx:2113
 #2  0x7fffd2ea856e in SvxShape::_getPropertyValue (this=0x21c1f38,
 PropertyName=CharBackColor) at
 /home/vmiklos/git/libreoffice/master/svx/source/unodraw/unoshape.cxx:1797

 nWhich = 0 sounds buggy, maybe you advertise your new UNO property in a
 generic property map, but in case of form controls, the underlying
 implementation doesn't handle that?

 Thanks,

 Miklos

From 92ff792570b1b56c5fa135d3635f169f084cd887 Mon Sep 17 00:00:00 2001
From: matteocam matteo.campane...@gmail.com
Date: Fri, 11 Jul 2014 14:58:55 +0200
Subject: [PATCH] CharBackColor advertised in unoshap2.cxx
To: libreoffice@lists.freedesktop.org

Change-Id: I0111ab571e23e37f5986301366836623476ed214
---
 svx/source/unodraw/unoshap2.cxx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/svx/source/unodraw/unoshap2.cxx b/svx/source/unodraw/unoshap2.cxx
index b732526..1f45dbe 100644
--- a/svx/source/unodraw/unoshap2.cxx
+++ b/svx/source/unodraw/unoshap2.cxx
@@ -680,7 +680,7 @@ SvxShapeControlPropertyMapping[] =
 { RTL_CONSTASCII_STRINGPARAM(CharKerning), RTL_CONSTASCII_STRINGPARAM(FontKerning) },
 { RTL_CONSTASCII_STRINGPARAM(CharWordMode), RTL_CONSTASCII_STRINGPARAM(FontWordLineMode ) },
 { RTL_CONSTASCII_STRINGPARAM(UNO_NAME_EDIT_CHAR_COLOR),   RTL_CONSTASCII_STRINGPARAM(TextColor) },
-   // { RTL_CONSTASCII_STRINGPARAM(CharBackColor) }, // FIXME(matteocam)
+{ RTL_CONSTASCII_STRINGPARAM(CharBackColor),   RTL_CONSTASCII_STRINGPARAM(CharBackColor) },
 { RTL_CONSTASCII_STRINGPARAM(CharRelief),   RTL_CONSTASCII_STRINGPARAM(FontRelief) },
 { RTL_CONSTASCII_STRINGPARAM(CharUnderlineColor),   RTL_CONSTASCII_STRINGPARAM(TextLineColor) },
 { RTL_CONSTASCII_STRINGPARAM(UNO_NAME_EDIT_PARA_ADJUST), RTL_CONSTASCII_STRINGPARAM(Align) },
-- 
1.8.3.2

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Chained Text Boxes in Draw - Report 6/07/2014

[Matteo Campanelli]

Hi,
Last week there was little coding and only some more insights on which
parts of the code should be affected:
- found how Writer deals with tags for chained text boxes;
- AutoFit code may be a good point of reference for overflow check;
- the solution may involve marking the part of the text where the break
should occur in editeng, letting drawinglayer separately render these two
portions of text in the right places;
- more knowledge on the role of FormatDoc and CreateLines.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Chained Text Boxes in Draw - Report 29/06/2014

[Matteo Campanelli]

Hi,
I'm trying to implement chained text boxes in Draw, i.e. linking boxes
logically so that text that cannot fit in one can overflow in its successor.

Last week I spent some time to progress on the following subgoals:
- take inspiration from how Writer does it (such a feature is already
present for Writer frames);
- figure out in which part of the code in editeng should be modified to
achieve the same result in Draw.

In general I'm looking at the code to find answers to the following
questions:
(a) how can one observe an overflow of text in a frame/box?
(b) after the point where overflow occurs is found, how to 'assign' the
remaining text to the successor?
(c) what kind of abstractions are used for text (paragraph potions, line
portions) during layouting and how to use them?

Although I found some important references in the code, my findings are
still incomplete and my few small experiments so far have failed.
Below I will try to elaborate more on some related code references I came
to know about.


In Writer
---

First, the way Writer carries around information about
predecessor/successor in chains is by means of a derived class of
SfxPoolItem, SwFmtChain
http://docs.libreoffice.org/sw/html/classSwFmtChain.html.
In formatting phase, however, this information seems to be accessed
directly from frames themselves ( SwFlyFrm
http://docs.libreoffice.org/sw/html/classSwFlyFrm.html ) by the methods
GetNextLink/GetPrevLink.
Then I tried to figure _how_ this information was used from formatting
routines. Breaking in GetNextLink, however, has a very high rate of hit and
has not been helpful in any way (I couldn't get any intuition from the
backtrace). Neither has been reading manually all the code this method is
referenced by (from Writer docs).
So far I assuemd this was the only point of access to that information
(successor), this hypothesis might be false or that code is too complicated
for my eyes at this stage.

In Draw
--

Although knowing how Writer does it would probably be useful, what is
necessary is understanding where to modify formatting code in Draw.
Two crucial methods seems to be:
1) ImpEditEngine::FormatDoc
2) ImpEditEngine::CreateLines (called by FormatDoc for each paragraph)

CreateLines's responsibilities seem to be to restructure the lines in a
paragraph (if they changed) so that they fit in the X boundaries.

FormatDoc's responsibilities seem to include:
- calling CreateLines for each paragraph portion,
- update some view's information if the height of the paragraph changed.

It seems plausible that FormatDoc is the place where an overflow event is
observed (directly or indirectly, by invoked methods) and text should be
assigned to its next link in the chain if such an overflow occurs

This week
-

Current goals include understanding FormatDoc's code further trying to
answer questions (a) and (b) above.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Blogging for GSoC - Links to technical blogs?

[Matteo Campanelli]

Hi all,
I'm documenting some of the implementation process for enabling text
background color in Draw.
It's my first time doing this and I feel I have little clue of what is a
good way to write on programming, especially in a tutorial fashion.

Are there any technical blogs  (maybe even GSoC/LO related) you think I may
look at?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Text Background Color in Draw - Report 22/06/2014

[Matteo Campanelli]

Hi all,
last week I have obtained a working solid text background color; old issues
has been fixed and it is now possible to use an arbitrary background color.
Moreover, the code now uses a proper Edit Engine attribute and the latter
is connected to the UNO API.

I am currently writing a few blog posts to document what I learnt so far.

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] Text Background Color in Draw - Report 14/06/2014

[Matteo Campanelli]

Hi all,
last week focused on exploring the problems related with finding the source
of the issue for the text background color not working in non-edit mode.
Currently the problem has been identified in the drawinglayer module (for a
more detailed discussion see
http://lists.freedesktop.org/archives/libreoffice/2014-June/061806.html ).

The main task of this week is closing the subgoals in the thread cited
above, thus getting solid text background working also in non-edit mode.

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: EditEng - Switch from edit to non-edit mode - Code references?

[Matteo Campanelli]

Hi all, just a follow up on some findings on this issue that I wanted to
share.

On Sun, Jun 8, 2014 at 12:43 AM, Kohei Yoshida kohei.yosh...@collabora.com
wrote:

   Does anyone know any point I should be looking at?

 Based on my experience with the edit engine code and your description,
 the first place I would look at is class EditTextObject, and the
 EditEngine::CreateTextObject() method.

Kohei, thanks for the tip - the issue seemed to be somewhere else however.

Summarizing once again, the problem was that I did get a text background
color in edit-mode but not in non-edit mode.
The problem seems to lie in the drawinglayer module, which takes care of
static rendering of text (thanks, Thorsten :-) ). In fact, currently, this
module knows nothing about text-portion-specific text color.

Rendering of text in this module seems to work (_roughly_) in this way:
(1) information on font (text color, underlining, italic...) are passed
from an external module [this is still subject of exploration],
(2) these font features are encapsulated in object of classes
TextFooPortionPrimitive2D,
(3) finally, the class VclProcessor2D makes the actual rendering out of
these primitives (by calling the ordinary text drawing methods from
OutputDevice).

Getting back to text fill color, the issue must be fixed at all three
levels:
(1') the fill color information should be passed by other modules,
(2') TextFooPortionPrimitive2D (probably TextSimplePortionPrimitive2D)
should be able to carry information on text fill color
(3') VclProcessor2D should pass this information to OutputDevice
appropriately.

I'm currently working on (1') and (2') but today I made an experiment and
the problem at level (3) is basically been figured out.

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

[GSoC] Text Background Color in Draw - Report 08/06/2014

[Matteo Campanelli]

Hi all,
last week was admittedly very little coding and mostly
debugging/(un)understanding/struggling:
- Text Fill color now works from editeng, but currently only under
edit-mode;
- I started identifying parts of code to make the background color a
stand-alone attribute (currently its inner workings are coupled with the
Underline attribute).

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Adding a new EE_CHAR_* attrib id

[Matteo Campanelli]

Hi all,
I am trying to add a new text attribute in EditEng (background color) and I
had a couple questions on the process:

*Premise*:
I already modified some obvious places:
- i added classes SvxBackgroundColorItem and EditCharAttribBackgroundColor
- i defined EE_CHAR_BKGCOLOR and included its use in several
switch...case-s where other EE_CHAR_* tags are dealt with.

1) I'm asking help to understand where these attributes are created after
the document model is modified, for example:
 - which methods are called to create a Color attribute after fo:color is
read in a document?
 - which methods are called to create a Color attribute after the user sets
a particular font color?

2) SfxItemPool and SfxPoolItem seem important classes for the purposes
above. I stumbled upon the method SfxItemPool::SetVersionMap used in
editdoc.cxx to set some version maps. From some of the comments in that
file I suspect that these maps may have to be modified to include the new
EE_CHAR_* I created. But no clue on that.
Does anyone know what the method SetVersionMap actually does and whether i
should modify the version maps set in the constructor of EditEngineItemPool?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

EditEng - Switch from edit to non-edit mode - Code references?

[Matteo Campanelli]

Hi all,
I'm working on drawing arbitrary text fill colors in Draw and currently my
code
- draws correctly (or almost correctly) a fill color when in EDIT mode;
- draws something unexpected in NON-EDIT mode-

I am trying to debug what happens when the switching between EDIT and
NON-EDIT occurs (e.g. which functions take care of setting the state of
OutputDevice and so on from EditEng).
Does anyone know any point I should be looking at?
Or does anyone have any suggestion on how to proceed for debugging?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: EE_EDIT_CHAR_BKGCOLOR breaks unit test?

[Matteo Campanelli]

On Tue, May 27, 2014 at 8:13 PM, Thorsten Behrens 
t...@documentfoundation.org wrote:


 warn:legacy.tools:12168:1:editeng/source/editeng/eerdll.cxx:165: ITEMCOUNT
 geaendert, DefItems nicht angepasst!

 In English: someone changed ITEMCOUNT, but failed to adjust
 DefItems. Did not check though if that happens also w/o your
 change. Beyond that, after Error: a unit test failed, please do one
 of..., there's some helpful blurb on what to do next. ;)


Fixed.
That actually helped a lot! :-)

Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Using OutputDevice::DrawTransparent fails

[Matteo Campanelli]

Some further experiments:
- changing the text color to non-black did not change the grey-ish
background for the arrow's text;
- using SetTextFillColor immediately before does not change anything;
- debugging inside DrawTransparent I've seen that there is a return false
that is triggered three frames deeper: DrawTransparent -
OutputDevice::DrawTransparentNatively - SalGraphics::DrawPolyPolygon -
X11SalGraphics::drawPolyPolygon.
In the last function this if-statement is triggered and the polypolygon is
never drawn I suspect:
[in core/vcl/unx/generic/gdi/salgdi.cxx:1023 ]

// cannot handle pencolor!=brushcolor yet
if( (nPenColor_ != SALCOLOR_NONE)
  (nPenColor_ != nBrushColor_) )
return false;


*Errata on my last commit message*: It is mpGraphics-DrawRect to be
commented, not DrawTextRect.

Matteo


On Tue, May 27, 2014 at 1:57 PM, Matteo Campanelli 
matteo.campane...@gmail.com wrote:

 Hi all,
 i was trying to set a transparent background in text areas in Draw.

 I replaced the call to mpGraphics-DrawRect in OutputDevice::ImplDrawText
 with a call to DrawTransparent on the same area. However the result has
 issues such as [see attached picture]:
 - not giving the expected color (the arrow text in the picture should be
 the same color as the text area's),
 - leaving old rendering leftovers around when text is moved (or the
 related arrow in this case).

 I tried to debug how other transparent areas are drawn but that didn't
 give much insight.
 Does anyone any experience with this or any guess on what may be going
 wrong?

 Thanks,
 Matteo



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

EE_EDIT_CHAR_BKGCOLOR breaks unit test?

[Matteo Campanelli]

Hi,
In my last commit I added a new entry to core/include/editeng/eeitem.cxx:
EE_CHAR_BKGCOLOR.
I put it at the end of the char attributes updating all subsequent values
consistently (all incremented by one).
Still, it broke unit test for editeng_core.
Is there some check I'm missing?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] SetTextFillColor(COL_BLUE) makes blu too dark in Draw

[Matteo Campanelli]

Hi,
I was experimenting with text background colors in Draw (see attachment).
I used OutputDevice::SetTextFillColor to set the color of underlined text
to COL_BLUE.
The background color of the text area is also set to blue but the one for
the underlined text (i.e. the one I'm setting) is darkened for some reason.
Anyone has an idea of what this may be related to?
Are there situations (selection?) where Vcl just makes this kind of changes
to colors?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] SetTextFillColor(COL_BLUE) makes blu too dark in Draw

[Matteo Campanelli]

Fixed.
Sorry everybody, I was using a wrong assumption:
COL_BLUE (#80) is _not_ the same as the Blue one selects from the
Draw standard palette (#FF).



On Sat, May 24, 2014 at 3:12 PM, Matteo Campanelli 
matteo.campane...@gmail.com wrote:

 Hi,
 I was experimenting with text background colors in Draw (see attachment).
 I used OutputDevice::SetTextFillColor to set the color of underlined text
 to COL_BLUE.
 The background color of the text area is also set to blue but the one for
 the underlined text (i.e. the one I'm setting) is darkened for some reason.
 Anyone has an idea of what this may be related to?
 Are there situations (selection?) where Vcl just makes this kind of
 changes to colors?

 Cheers,
 Matteo


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC 2014] Code pointers for text properties in Draw

[Matteo Campanelli]

Hi all,
I'm working on adding text background color to Draw text frames but I
suspect I'm having troubles finding my way through the basics of the whole
application's architecture.
Browsing through code in sd/,  I haven't found anything that seemed to deal
specifically with text properties.
I suppose most of the responsibility for text features is in some external
module (editeng, by any chance?), but I don't understand where it is that
Draw-specific code makes use of these features.

Could anyone point to any documentation/code I could look at or could
anyone help me get clarity on this point?

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH] fdo#53472 Created Dynamic Integral Node classes. Integrals size made dependent on body.

[Matteo Campanelli]

Hi everybody,
I am posting my first LO patch.
https://gerrit.libreoffice.org/#/c/8569/

This code adds a new node structure in StarMath to deal with dynamic
integrals. I introduce a command intd in addition to the standard int,
intd is able to resize according to the size of its argument.
This is supposed to be a first step in the potential inclusion of other
dynamically-sized symbols for sums, products...

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoc 14] On Improve Text Boxes in Draw - towards a more specific description and starting directions

[Matteo Campanelli]

Hi,

On Tue, Mar 18, 2014 at 7:18 AM, Fridrich Strba 
fridrich.st...@graduateinstitute.ch wrote:

 On 18/03/14 06:23, Matteo Campanelli wrote:
  - /text background color:/
 
  It seems to me that it is possible to specify a text box background
  in color in Draw. Are we then referring to background color of the
  text only?

 Yes, it is possible to specify the colour of the text box itself, but it
 is not possible to specify the background of the text itself. The
 problem can be seen in import filters, where in the original
 applications the text, that has non-transparent (i.e. white) background,
 is describing lines (like in technical drawings). Because the background
 is transparent, the text is basically unreadable because of the line
 that is under it.


I see, but thinking again I'm wondering: wouldn't specifying a text box
with a certain transparency style be enough for that family of issues? Or
is there something else text background may be required for?


 In the ODF file-format, there is a possibility to specify a sequence of
 frames where text, when arrives at the end of one frame overflows into
 the next one.

I made a search in the specification and I believe it is
draw:chain-next-namehttp://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-draw_chain-next-name
you
are referring to. Is that correct?

So, implementing this feature would require to:
- allow Draw to parse properly the attribute above (where does parsing of
attributes and similar happens in the code architecture?);
- implement the expected overflowing behavior (this should be simple
enough, but still I am not sure where text boxes are handled in Draw's
code);
- allow text boxes to specify a next link from the UI (maybe optional for a
Summer Project?)


  Is there already something like this in Draw or LO in general, i..e
  ways. to reference other objects' properties explicitly?

 Not in Draw yet. We have in LibreOffice already this feature implemented
 for Writer, where you can do this kind of linked frames.


I see. Could you please exemplify I could I test this in Writer?


  - /support of style:/
 
 I would in the first time look what is possible to specify in the Style
 and Formatting in Draw and what is possible in Writer. The first goal
 would be to bring them at the same level.


I'm starting to believe that the first three features (text background,
overflow in frames and hyphenation)
could be sufficient for a summer project; adding more may make it risky.


 Now, be aware that we might discover that any of this task is more
 complicated then what we think.


 Thanks for your interest. I hope that I answered at least some of your
 questions.

You definitely did, thank you.
Now my goal is to get a better grasp of how to approach these problems in
the code and also which other subtasks they can be split it.

Cheers,
Matteo


 Cheers

 Fridrich


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoc 14] On Improve Text Boxes in Draw - towards a more specific description and starting directions

[Matteo Campanelli]

Hi all,
I'm Matteo, I'm planning to apply for GSoC and I'm wondering if anyone
could answer a few questions on the GSoC idea proposal in the subject
([1]https://wiki.documentfoundation.org/Development/GSoC/Ideas#Improve_Text_Boxes_in_Draw
).
Some specific tasks that would be involved in this project are not totally
clear to me yet.
Simply enough, the general problem seems to be that of enhancing text
frames in Draw.
Quoting from the official description, some missing features of text frames
are:
(my personal comments and questions right indented below each item)

- *text background color:*

It seems to me that it is possible to specify a text box background in
color in Draw. Are we then referring to background color of the text only?
Would that be, in other words, some colored rectangle around only part of
the text in the box (a bit like text background color in Writer)?

- *flow of contents from one frame to another:*

I am not sure I know what we are talking about here, but I would imagine it
as The text in a frame may (dynamically) constitute part of the text in
another frame.
Let me illustrate this: Alice has two text frames, named respectively TF1
and TF2. The text in TF1 may look like:

Lorem ipsum...
As illustrated in the box above:
[TF2.text]
Ut enim ad minim...

Here, the macro TF2.text would expand to whatever text is contained in the
other frame.
Is this in any way close to what the project description is talking about?
Is there already something like this in Draw or LO in general, i..e ways.
to reference other objects' properties explicitly?

- *hyphenation:*

About this point, I wanted to ask a more technical and at the same time
general type of question:
from the documentation on the class ImpEditEngine
([2]http://docs.libreoffice.org/editeng/html/classImpEditEngine.html#a6163e18b8db452f3324561f92542)
I see that there are getters and setters for hyphenators and a method
called ImpBreakLine. This suggests to me that ImpEditEngine may be involved
directly in how or whether hyphenation is done in text frames.
How does this class actually works?
What are its responsibilities (since it seems to deal with a LOT of stuff)?
Could anyone exemplify or point how this class affects hyphenation in, say,
Writer or any other parts of LO? (or alternatively could anyone redirect me
to some semi-digestible snippets of code in LOI see  where this magic
happens?)


- *support of style:*

I see that Draw already has a Style and Formatting dialog offering
several options. What would be the specific enhancements for this point?


I had a hard time finding which source files in sd/ are strictly related to
text frames, could anyone please give me a direction for that?
(textapi.{hxx,cxx} by any chance?)

I'm still a little bit confused on the specific scope/aim of the items
above, does anyone have an opinion on how much/which parts of this project
idea would be sensible to incorporate in a concrete proposal for the summer?

Thank you for your time.
Best,
Matteo

References:
[1] Original GSoC idea description
(linkhttps://wiki.documentfoundation.org/Development/GSoC/Ideas#Improve_Text_Boxes_in_Draw
)
[2] Reference documentation for ImpEditEngine
(linkhttp://docs.libreoffice.org/editeng/html/classImpEditEngine.html#a6163e18b8db452f3324561f92542
)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [GSoC] On ODF Formulas in Writer

[Matteo Campanelli]

Okay, thank you guys for all the help.
In the meantime I got my patch accepted! :)

Given the news (ODF formulas in Writer not being a valid GSoC talks
anymore), I'm going to apply for another project but in case my submission
to GSoC were not successful I might consider working on a sub-part of this
issue anyway this summer 'cause it had intrigued me at the beginning.

Best,
Matteo


On Tue, Mar 11, 2014 at 10:23 PM, Kohei Yoshida kohei.yosh...@collabora.com
 wrote:

 On Tue, 2014-03-11 at 12:53 +0100, Michael Stahl wrote:
   However, for now, I would suggest focusing getting your easy hack
  ready
accepted; that's required even in case at the end you're
  interested in
   some other LibreOffice idea.
 
  absolutely - here are usually more GSoC applicants than available
  mentors, and the most important thing to get accepted is to show that
  you can get useful work done.  if we find that this one won't work
  out,
  it's always possible to choose a different GSoC project.

 And it appears that this idea has been moved out of the Ideas page,
 which means it's no longer a valid GSOC task.

 To be honest, I don't even know why this task was left on that page in
 the first place.  I believe it was one of those left-over tasks that we
 forgot to clean up.

 Kohei


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[PATCH]

[Matteo Campanelli]

Hi everybody!
Attached there is a patch for bug 53472.
It allows to use adaptively-sized integral symbols in Starmath by means of
a new command intd.

Cheers,
Matteo
From 8960e64124a29fe77e75cd04c3609ba55ea2eefd Mon Sep 17 00:00:00 2001
From: matteocam matteo.campane...@gmail.com
Date: Tue, 25 Feb 2014 14:37:55 -0500
Subject: [PATCH 1/5] Created Dynamic Integral Symbols class

Change-Id: Id86ea4292126b36c37d973ac4acbcc1e5cb7ed97
---
 starmath/inc/node.hxx| 28 +++-
 starmath/source/node.cxx | 23 +++
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/starmath/inc/node.hxx b/starmath/inc/node.hxx
index bce53f2..5335e6a 100644
--- a/starmath/inc/node.hxx
+++ b/starmath/inc/node.hxx
@@ -73,7 +73,7 @@ enum SmNodeType
 /*10*/ NBINDIAGONAL,   NSUBSUP,NMATRIX,NPLACE, NTEXT,
 /*15*/ NSPECIAL,   NGLYPH_SPECIAL, NMATH,  NBLANK, NERROR,
 /*20*/ NLINE,  NEXPRESSION,NPOLYLINE,  NROOT,  NROOTSYMBOL,
-/*25*/ NRECTANGLE, NVERTICAL_BRACE, NMATHIDENT
+/*25*/ NRECTANGLE, NVERTICAL_BRACE, NMATHIDENT,NDYNINT
 };
 
 
@@ -618,6 +618,32 @@ public:
 void Accept(SmVisitor* pVisitor);
 };
 
+
+
+/** Dynamic Integral symbol node
+ *
+ * Node for drawing dynamicall sized integral symbols.
+ *
+ * XXX: It might be created a parent class SmDynamicSizedNode
+(for both dynamic integrals, roots and other dynamic symbols)
+
+ */
+class SmDynIntegralNode : public SmMathSymbolNode
+{
+sal_uLong  nBodyWidth;  // width of body (argument) of integral sign
+
+public:
+SmDynIntegralNode(const SmToken rNodeToken)
+:   SmMathSymbolNode(NDYNINT, rNodeToken)
+{}
+
+sal_uLong GetBodyWidth() const {return nBodyWidth;};
+virtual void AdaptToX(const OutputDevice rDev, sal_uLong nHeight);
+virtual void AdaptToY(const OutputDevice rDev, sal_uLong nHeight);
+
+void Accept(SmVisitor* pVisitor);
+};
+
 
 
 
diff --git a/starmath/source/node.cxx b/starmath/source/node.cxx
index 6ffd0fb..9268e55 100644
--- a/starmath/source/node.cxx
+++ b/starmath/source/node.cxx
@@ -622,6 +622,7 @@ void SmNode::DumpAsDot(std::ostream out, OUString* label, int number, int id,
 case NRECTANGLE:   outSmRectangleNode; break;
 case NVERTICAL_BRACE:  outSmVerticalBraceNode; break;
 case NMATHIDENT:   outSmMathIdentifierNode; break;
+case NINTDYN:outSmDynIntegralNode; break;
 default:
 outUnknown Node;
 }
@@ -2296,6 +2297,24 @@ void SmRootSymbolNode::AdaptToY(const OutputDevice rDev, sal_uLong nHeight)
 
 /**/
 
+void SmDynIntegralNode::AdaptToX(const OutputDevice /*rDev*/, sal_uLong nWidth)
+{
+// XXX: copied from SmRootSymbol for now
+//nBodyWidth = nWidth;
+}
+
+
+void SmDynIntegralNode::AdaptToY(const OutputDevice rDev, sal_uLong nHeight)
+{
+// XXX: copied from SmRootSymbol for now
+// some additional length so that the horizontal
+// bar will be positioned above the argument
+//SmMathSymbolNode::AdaptToY(rDev, nHeight + nHeight / 10L);
+}
+
+
+/**/
+
 
 void SmRectangleNode::AdaptToX(const OutputDevice /*rDev*/, sal_uLong nWidth)
 {
@@ -3194,6 +3213,10 @@ void SmRootSymbolNode::Accept(SmVisitor* pVisitor) {
 pVisitor-Visit(this);
 }
 
+void SmDynIntegralNode::Accept(SmVisitor* pVisitor) {
+pVisitor-Visit(this);
+}
+
 void SmRectangleNode::Accept(SmVisitor* pVisitor) {
 pVisitor-Visit(this);
 }
-- 
1.8.3.2

From a9019baf943d56c225e02d7c4f87119c2ba79d12 Mon Sep 17 00:00:00 2001
From: matteocam matteo.campane...@gmail.com
Date: Tue, 25 Feb 2014 21:47:22 -0500
Subject: [PATCH 2/5] Added files

Change-Id: I71862f579784890d3075ff9f5a63bd756a55b93d
---
 starmath/source/mathtype.cxx| 2 ++
 starmath/source/mathtype.hxx| 2 +-
 starmath/source/ooxmlexport.cxx | 1 +
 starmath/source/rtfexport.cxx   | 1 +
 4 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/starmath/source/mathtype.cxx b/starmath/source/mathtype.cxx
index b90b79d..8212421 100644
--- a/starmath/source/mathtype.cxx
+++ b/starmath/source/mathtype.cxx
@@ -2516,6 +2516,7 @@ void MathType::HandleOperator(SmNode *pNode,int nLevel)
 switch(pNode-GetToken().eType)
 {
 case TINT:
+case TINTD:
 if (nOldVariation != 0xff)
 pS-WriteUChar( sal_uInt8(0x18) ); //selector
 else
@@ -2640,6 +2641,7 @@ void MathType::HandleOperator(SmNode *pNode,int nLevel)
 pS-WriteUChar( sal_uInt8(0x86) );
 pS-WriteUInt16( sal_uInt16(0x222B) );
 case TINT:
+case TINTD:
 case TLINT:
 pS-WriteUChar( sal_uInt8(CHAR) );
 pS-WriteUChar( sal_uInt8(0x86) );
diff --git 

Matteo Campanelli license statement

[Matteo Campanelli]

All of my past  future contributions to LibreOffice may be licensed under
the MPLv2/LGPLv3+ dual license.

Matteo Campanelli
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [PATCH]

[Matteo Campanelli]

Thanks Adam.
I followed the procedure and now the code is on Gerrit.


On Thu, Mar 13, 2014 at 5:18 AM, Adam Fyne adam.f...@cloudon.com wrote:

 Hi Matteo,

Thanks for working on this issue and having a patch
 ready for review! However, the proper way to submit patches
 for code-review (and subsequent submission on master) is
 using the gerrit. You can find details on how to do that 
 herehttps://wiki.documentfoundation.org/Development/gerrit
 .

 Best,
 Adam


 On Thu, Mar 13, 2014 at 9:52 AM, Matteo Campanelli 
 matteo.campane...@gmail.com wrote:

 Hi everybody!
 Attached there is a patch for bug 53472.
 It allows to use adaptively-sized integral symbols in Starmath by means
 of a new command intd.

 Cheers,
 Matteo

 ___
 LibreOffice mailing list
 LibreOffice@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/libreoffice




 --

 [image: appicon.png]


 *Adam Fyne*

 Twitter http://www.twitter.com/cloudoninc | 
 LinkedInhttp://www.linkedin.com/company/cloudon
  | Facebook http://www.facebook.com/cloudoninc | 
 Bloghttp://site.cloudon.com/blog





___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[GSoC] On ODF Formulas in Writer

[Matteo Campanelli]

Hi all,
I'm Matteo, a PhD student in Computer Science at City University of New
York.
I am planning to apply to GSoC '14 and a few weeks ago I started hacking
LibreOffice (I've been working on this Easy
Hackhttps://bugs.freedesktop.org/show_bug.cgi?id=53472
).

I'm writing to start a discussion and ask some questions on the idea
project in the subject of this email
([1https://wiki.documentfoundation.org/Development/GSoC/Ideas#ODF_Formulas_in_Writer
]).

Could you please give me some feedback on my understanding of the
definition of the problem and current related work in LO (see bullets
below)?
Also - most important question (!!) - would there be anyone interested in
mentoring this project?

My understanding of the issue:
- Currently Writer uses its own, non-standard syntax for formulas. At the
moment this syntax is both what is used/typed by the user and the one used
for internal computations. (At a first glance, the class
SwCalchttp://opengrok.libreoffice.org/search?q=project=coredefs=SwCalcrefs=path=hist=seems
to be responsible for both parsing and interpreting these formulas,
is that right?)
- The goal of the project would be to enable users to write formulas in the
ODF Format 
[2]http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html
and use this same format for the internal computations.
- As far as I have understood, we may use the ixion library
[3]https://gitorious.org/ixion to
interpret ODF-style formulas. This library is already used by Writer for
interpreting formulas in doc/docx files (which, I suppose, are first
converted to the actual ODF format). [is this point of my interpretation
correct? Could anyone provide code pointers for the computation of formula
for .doc files?]
- Part of the project will have to deal with import/export filters and
backward compatibility: first, files with formulas in the old-syntax should
still be parsed correctly; second, users should have the option of saving
in the old syntax or in the default new ODF syntax.

Also, I have two additional questions:
- the project idea page mentions changes in the code for the formula input
bar. What should these changes to the UI consist of specifically? Are they
mostly related to the strings produced by using the Formula dropdown menu
in the bar?
- Can anyone who is into the code roughly assess the relative hardness of
the three subparts of this project (i.e. refactoring to use ODF and
delegation to ixion, changes in the UI, adapting import/export filters)? In
other words, which of these parts (if any) is likely to take longer
compared to the others?

References:
[1] ODF Formulas in writer - Original GSoC Project Idea Page
(linkhttps://wiki.documentfoundation.org/Development/GSoC/Ideas#ODF_Formulas_in_Writer
)
[2] Open Formula - Official specification
(linkhttp://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html
)
[3] Ixion Library (link https://gitorious.org/ixion)

Comments of any kind are appreciated.
Thanks in advance for your feedback!

Cheers,
Matteo
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice