[scribus-dev] Preparations for GSoC

Sun May 15 18:02:02 UTC 2011

Hello Leonard, and thanks for your prompt reply.

2011/5/15 Leonard Rosenthol <lrosenth at adobe.com>:
> Some comments/corrections on Tables and InDesign.
>
>>Something that might be different from how tables
>>will work in Scribus is that in Indesign, tables can only exist as
>>inline objects inside a text frame, not as objects on their own.
>>
> That's because by having them as part of a text frame, you can then have other things wrap around them and they act "inline".  Having a "table frame" doesn't really fit the model that most users are used to - it also makes it more complex to implement when you start thinking inline.  It also helps with selects that cross the table boundary (eg. Some text and some table).

Right. I'm aware of the concept of inline vs. non-inline of course.
However, in Scribus text can flow around objects that are not inline.
You're right about "acting" inline though, that won't be possible with
the "tables as a PageItem" approach, unless Scribus has some general
support for making any PageItem inline, and I don't think it has. Can
anyone enlighten me here? What's the state of support for inline
objects, is there any support at all?

>
>
>>Another thing which I think
>>will naturally be different in Scribus is that in Scribus, editing of
>>item properties is mostly done through the Properties palette, and not
>>so much through dialogs that pop up (thankfully! because table editing
>>in Indesign seems to be very dialog-intense).
>>
> This is where your inexperience with InDesign shows :).  If you look closely, you will see that it's properties bar enables full control w/o ever seeing a single dialog.  And if you don't like the bar, you can also show the Table Palette (floating or docked) and change things there too...

Guilty as charged :) I only got it installed yesterday and obviously I
haven't played around with it enough, but missing both the Table
Palette and the fact that there's actually styles for both tables and
cells was quite bad on my part.

>
>
>>In Indesign, tables, rows and columns are resized by click-dragging,
>>and I'm guessing this is how we want it to work in Scribus too?
>>
> You can also type explicit values into the properties bar or palette.

Yes, and I expect something similar is wanted in Scribus too.

>
>
>>In Indesign, tables, rows and columns are resized by click-dragging,
>>and I'm guessing this is how we want it to work in Scribus too?
>>
> Not only does InDesign have named styles for an entire table, we also have Cell styles for individual cells (or groups of them, such as Rows or Columns).

Yes, don't know how I missed those.

>
>
>>In Indesign, tables, rows and columns are resized by click-dragging,
>>and I'm guessing this is how we want it to work in Scribus too?
>>
> Don't forget individual row and column selection as well.

Right.

>
>
>>Using text frames for cell content
>>
> While this is one of the most common first pass methods for how to do tables - you may (will) find that it doesn't work well when you wish to enable cross-cell and cross-table selection and manipulation.

This is indeed a valid concern, and one I'll have to think long and hard about.

>
>
> Hope that helps....

Yes, again, thanks a lot for the quick reply.

So.. In light of Leonards response here. Do we still think that tables
as page items is the way forward? Because I thought that had been
pretty much agreed on. My idea was that the tables would initially be
made as page items that could only be placed freely on the page, not
inline in text frames, and that later on, Scribus text layout engine
could possibly be given the ability to place items such as tables
inline (with modifications to tables to support working in this new
setting). Now I'm not so sure anymore, and I'd really like it if more
of you could answer.

Regards,
Elvis

>
> Leonard
>
> -----Original Message-----
> From: Elvis Stansvik [mailto:elvstone at gmail.com]
> Sent: Sunday, May 15, 2011 9:58 AM
> To: Scribus Development Mailing List
> Subject: [scribus-dev] Preparations for GSoC
>
> Hello Scribus folks,
>
> Summer is getting closer fast, and while I'm exceedingly busy with
> preparations for my upcoming exams, I think it's important I get at
> least some preparations for GSoC done so that I can get a flying start
> and have a clear direction for my project once May 28 comes and exams
> are over. I've started to write down some preliminary questions and
> thoughts around my project and put them on the wiki [1], but I'll
> include that page almost verbatim below, sans some of the wiki markup,
> so that we can discuss it on-list. The wiki has a couple of
> screenshots from Indesign, so perhaps you'll still want to check that
> out. I'll extend/update the page as my project progresses.
>
> I would be very grateful if you could read through these questions
> once and give your comments. I'm especially interested in things where
> you feel "no no no, not like that", or if there are things where you
> know things will get hairy technically. I think it's important we're
> on the same page regarding how the tables should work in Scribus from
> the get-go, so any and all input is relevant.
>
> Lastly, in the midst of everything I believe I've never asked who will
> be my mentor this summer, might be good to know :) Malex? MrB?
>
> Best regards,
> Elvis
>
> [1] http://wiki.scribus.net/canvas/GSoC_2011_Tables
>
> = GSoC 2011 Tables =
> This page contains technical and functionality related considerations
> regarding the implementation of tables in Scribus as part of Google
> Summer of Code 2011. Here I'll try to keep an up to date document
> describing the design of the implementation, a list of open technical
> problems and questions regarding the functionality of the tables,
> including a couple of use cases as well as everything else concerning
> my work on bringing tables support to Scribus.
>
> == General Design ==
> As was outlined briefly in my project proposal, the tables in Scribus
> will be implemented as a new page item. Handling of cell content will
> be delegated to text frames.
>
> == Interaction Questions ==
> In the questions below, I refer quite a lot to Adobe Indesign. This is
> not because I see it as a template of good design or anything, it's
> just that I happen to have come across a copy of it which I have
> running under VirtualBox, and it helps to have something existing to
> discuss around.
>
> === Table Creation/Editing ===
> Is there a general consensus on how we want interaction with the
> tables to work? Looking at how tables work in Indesign CS5.5, their
> design is quite straight forward and works essentially as those found
> in word processors: The user is presented with a "Table" menu from
> which tables can be inserted and manipulated and formatted through
> dialogs that pop up. Something that might be different from how tables
> will work in Scribus is that in Indesign, tables can only exist as
> inline objects inside a text frame, not as objects on their own.
>
> I'm imagining that in Scribus, the user is able to freely position the
> tables on the page, while in the future, we can hopefully let the user
> insert the table item I'll be creating inline in running text by
> making it an inline object of some kind? Another thing which I think
> will naturally be different in Scribus is that in Scribus, editing of
> item properties is mostly done through the Properties palette, and not
> so much through dialogs that pop up (thankfully! because table editing
> in Indesign seems to be very dialog-intense). I guess we will have a
> new tab on the PP called "Table" that will be disabled unless a table
> is selected, similar to how it works for images?
>
> === Table/Row/Column Resizing ===
> In Indesign, tables, rows and columns are resized by click-dragging,
> and I'm guessing this is how we want it to work in Scribus too?
> Something that comes to mind is that for most items Scribus uses a
> modal way of interacting with the item: In the "normal" mode, the user
> is able to select, move and resize an item, while in the "editing"
> mode (entered by double-clicking) he/she is able to perform editing
> actions on the item, such as inserting text in text frames, or moving
> vertices of a polygon. Is this modal way of working something we want
> for tables as well, in order for them to fit in with the Scribus way
> of working? If so, I'm guessing actions such as column/row resizing
> should be available in the "editing" mode, while in the "normal" mode
> the user is only able to move/resize the table?
>
> === Styles ===
> A while ago I took an afternoon and investigated what it takes to
> create a new kind of style in Scribus, thinking this is something we
> might want for tables. It was mostly straight forward and I ended up
> with a primitive skeleton of a new style which is now in my Git repo.
> Since then however, I've started thinking; Are styles for tables (and
> even for rows/columns/cells) something we really want, or are they an
> unnecessary complication for small benefits? I don't know about other
> programs, but Indesign does not have named styles for tables. Tables
> are simply formatted by direct editing of properties for individual
> tables. How common are use cases where the user would really be
> hampered without support for named table (and possibly
> cell/row/column) styles? Would it be sufficient for Scribus if editing
> table properties is a per-table operation? I'd really like to get the
> opinion of other team members on this.
>
> === Cell Selection ===
> I'm guessing we want cell selection to work similar to word processors
> and Indesign, where a user is able to enter a "cell selection" mode by
> starting to select some text in a cell with the mouse and then
> dragging outside the cell boundaries?
>
> == Technical Questions ==
> Below are some of the technical questions I have to find answers to.
> Since the content of table cells will be represented using Scribus'
> regular text frames, several of the questions below are related to
> this.
>
> === Notification of Text Overflow in Text Frames ===
> Using text frames for cell content means the table will have to be
> notified when overflow occurs in a text frame, to be able to correctly
> re-layout the table starting from the row in which the overflow
> occurred. If we eventually want to have width-growing columns, we'll
> also need a way to be notified when a line break is about to occur in
> a text frame. So the question is; do text frames currently emit any
> signals to indicate that content is overflowing? It seems they are
> not, but one place where such a signal could possibly be emitted is in
> PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
> not be a correct solution though, perhaps the table should instead
> listen to insertions being made in the text frame, and query the frame
> for its overflow state using PageItem::frameOverflows()?
>
> In addition to being notified of when overflow happens, the table will
> also need to be able to query the text frame for the height of its
> content, to be able to resize it correctly during table layout. Is
> this possible using the current API? If not, what would it take to add
> it?
>
> === Editing of Cell Content ===
> As the text frames have their own modal way of being edited, and on
> top of that we'll probably have a modal way of editing tables (see
> above under Interaction Questions), how will we combine the two when
> it comes to editing cell content? I really don't think we want a
> multi-layered modal interaction, where the user first has to
> double-click the table, and then again double-click a cell in order to
> edit its content. Indesign is on the other extreme of this, there a
> user can directly edit the content of a table, without any modes of
> operation. I think what we want in Scribus is for the user to
> immediately be able to interact with the content of cells after the
> first double-click on the table. Or what do you think?
>
> On top of this is the question of keyboard navigation between cells,
> which I'm sure we want. The table will probably have to somehow filter
> the keyboard events before they hit the underlying text frame of the
> cell in order to get this to work.
>
> === Disabling Decorations / Resize Handles of Text Frames ===
> I will have to figure out how drawing of decorations, and possibly
> also the resize handles of text frames can be disabled. The table will
> only be interested in the text displaying / editing capabilities of
> the text frames, and will not want them to draw anything else such as
> borders, decorations or resize handles. Perhaps this is an easy thing,
> but still something I'll have to investigate.
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>