[scribus-dev] Fwd: Mid-week mini report

[Elvis Stansvik]

I realized it might be better to put this on the list instead.

Regards,
Elvis

---------- Forwarded message ----------
From: Elvis Stansvik <elvstone at gmail.com>
Date: 2011/6/29
Subject: Mid-week mini report
To: Craig Bradney <cbradney at scribus.info>


Hi Craig,

Since there's been quite few pushes by me in the past two days, I
thought I'd give you a little report on what I'm doing.

I've realized that the approach to painting I took will not work for
more complex borders or the joining of them. Since Monday I've been
working in a local branch (and also a lot with pen and paper) trying
to come up with a solution.

I must say this is one of the hardest problems I've ever faced, and
I'm surprised that something seemingly so simple can give me such
headaches. There have been moments when I almost despaired, but I
think I'm starting to see the light at the end of the tunnel.

There are a multitude of factors that makes the problem a hard one.
Let's begin with the requirements

1) Along each side of a single cell, the cell may share its border on
that side with N other cells, or with the table border. At each of
these N shared sections of the cell border, the shared borders should
be collapsed according to certain priority rules. These rules depend
on the border width, color, et.c., what kind of border it is (table or
cell) and as a last resort; the position of the owners of the borders
relative to each other (left wins over right, top over bottom).

2) After borders have been collapsed as described above, can
optionally be joined at the intersections. There are nine types of
intersections possible; four permutations of T-intersections, four
permutations of L-intersections and one +-intersection. If joining is
turned off, or two borders can not be joined, then either horizontal
borders should be drawn on top or vertical borders should be drawn on
top according to a border drawing order.

3) A border may consist of multiple sub-lines drawn on top of each other.

Both 1 and 2 are tricky, and adding 3) doesn't make it any simpler.
The adjustments that needs to be made to collapsed border sections in
order to join them properly are non-trivial, but let's consider a
regular T-intersection as an example:

If T is a regular T-intersection of collapsed border sections, and

- A is the vertical collapsed border section in T,
- B is the horizontal collapsed border section coming in from the left in T,
- C is the horizontal collapsed border section coming in from the right in T,

and the end points of A, B and C at the intersection is assumed to be
positioned on the table grid intersection. If we then limit ourselves
to the adjustment needed for just the top end points of the sub-lines
of A, then (very simplified) it's something like this in pseudo-code:

if (WantJoins && (A==B || A == C))
   // Joining is enabled and A is joinable with B or with C.
   Move each of the end points of the sub-lines of A up by half their
own width.
else:
   if (VerticalOnTop):
       Move each of the end points of the sub-lines of A up by
max(width of B, width of C).
   else:
       Move each of the end points of the sub-lines of A down by
max(width of B, width of C).

The max(...) thing is mostly to have some kind of visual
discrimination, in reality the width of any of A and B can be picked.

Handling of the other end points at the intersection is pretty much symmetrical.

Not until both end points of a collapsed border section have been
adjusted may it be painted (naturally).

My problems have mostly been finding a good way of iterating over the
table and painting all the borders with the above requirements in
mind, and without ever painting anything twice. It is very tricky.

Just thought I'd give you a glimpse of what I'm wrestling with at the
moment. Now on to some questions I have:

1) The entire table grid must be correctly offset in the Y direction
by half of the maximum width of the collapsed border sections found
along its top edge, and likewise in the X direction by half of the
maximum width of the collapsed border sections found along its left
edge. This means I need a way to be notified of style changes, since
if any of the relevant borders are changed, this offset needs to be
recalculated. But so far I've been unable to find out how to be
notified of changes in a given style. I'm interested in changes in the
actual used value, whether it was changed in a parent style or set on
the style itself.

2) For character and paragraph styles, there's a document-wide style
context (StyleSet) in ScribusDoc. But I can't find a matching one for
line styles. How come? As cell styles will be using line styles for
their borders, which is the correct style context to use for these?

Now on to hacking.

Cheers,
Elvis