Updates about Enhanced Database Ranges.
shetyeakash at gmail.com
Sat Jul 13 12:07:28 PDT 2013
I have many issues to look at concerning export of formatting information.
1. The ScStyleSheet(s) are not exported by LO Calc when xlsx->LO Calc ->new
xslx doc is done.
this is because through sc/source/filter/excel takes care about importing
the style information and creating ScStyleSheet(s) from it; there is no
code to export the style sheet data. So I am looking at coding in that so
that style information can be saved to excel as well. Currently I am
writing skeleton code and just SAL_DEBUGing around to figure things out in
the filter/excel area.
I am looking at writing <dxf> data into style.xml of the created xlsx
first. Seems no <dxf> style information is ever written by current code.
After <dxf> data is successfully written into the styles.xml of xlsx I will
move on to write in the <tableStyles> information, that will be very quick;
2. The database ranges created by excel (successfully imported into LO
Calc) are not exported to xlsx! Seems there is no code to export the
ScDBData objects to xlsx. I would like to achieve this after the style
export is done with. This is because the styles thing is more interrelated
to different tiny parts of code and will take a lot of time.
3. After the database ranges are successfully exported to xlsx I can work
towards including the <tableStyleInfo> data in the /tables/table#.xml of
the related database range.
All these tasks are big ones and once done will help not only alternating
database ranges feature but also the export of ranges and style sheets.
Please provide me any pointers/ high level flow of this export part while I
am investigating it within my little capacity. Please tell me how I must
approach stuff and any corrections or suggestions. Thank you guys.
On Mon, Jul 8, 2013 at 7:01 PM, Akash Shetye <shetyeakash at gmail.com> wrote:
> Progress so far is.
> +finally finished with import of column and row formatting data for tables.
> +progressing on exporting back to ooxml.
> Need to code faster since i am behind schedule. But I think I can cope up
> well. This week by thursday you should see export feature for ooxml in
> On Jun 4, 2013 1:15 AM, "Markus Mohrhard" <markus.mohrhard at googlemail.com>
>> Hey Akash,
>> 2013/6/2 Akash Shetye <shetyeakash at gmail.com>:
>> > Hey devs,
>> > Thank you moggi and kohei for helping me out on the IRC constantly.
>> > With the design I am describing now, the feature becomes an n-ternating
>> > alternating) row formatting (not just colouring) feature. Please help
>> > your advice and discussions.
>> > The feature design can be compartmentalised as follows:
>> > 1. The 'Row Formatting definition' part, where used selects the targeted
>> > database range and the styles to be applied to it.
>> > 2. The 'Row Formatting core' where DB Range code and this feature
>> > 3. The rendering end.
>> After reading this I think we need to split the task into smaller and
>> easier to handle steps. Hopefully it helps us to focus on the
>> important tasks for now. I'll explain some of the problems with your
>> proposal below but the general point is that we should work on the
>> model right now. Don't think about anything redering related, updating
>> references or similar stuff until we have implemented the model and
>> maybe have the import and export implemented. The visual
>> representation of the feature is something that we can later add but
>> is of less importance than you think right now.
>> > Row Formatting definition:
>> > [Data Structures]
>> > About the storage of this formatting information and how alternating
>> > formatting info will be defined:
>> > User defines each alternating format as a band, and as such 'n' number
>> > bands constitute particular n-ternating format. The user select the
>> > formatting options and the size of the band i.e, how many consecutive
>> > it will cover/applied to. When the user defines another band, the new
>> > will follow the previously defined band. Thus we can have more than just
>> > alternating colours for our DB ranges. Eg. define first band of size 1
>> > bold text, band 2 of size 3 italic text and band 3 of size 1 underlined
>> > text; for a range of 10 rows, the first will be bold followed by 3
>> > rows followed by 1 underlined row and so on..
>> > Every defined band for an Alternating row format will be stored as a
>> > ScDBDataRowFormat that will have the attributes: 1. index number which
>> > define the sequence of these bands 2. band size 3. Formatting
>> > (ScStyleSheet instance??). It has its method GetStyle() that returns the
>> > style to be applied
>> Let us limit ourself for now to 2 alternating styles. Extending this
>> later is easier than trying to implement everything at once.
>> > Many such ScDBDataRowFormat instances are added to a container which is
>> > part of ScDBDataRowFormatting object. This object represents the total
>> > you have created and also contains the defined style name you give to
>> > All such defined styles are added to a pool of ScDBDataRowFormatting
>> > objects; lets say this pool is represented by
>> > ScDBDataRowFormattingCollection (the names are getting scarily long), so
>> > styles once custom defined can be used again and again.
>> > Associating every ScDBData object with it's ScDBDataRowFormatting
>> > Every ScDBData object has an attribute of type ScDBDataRowFormatting
>> > is assigned to it by picking it up from the
>> > pool.
>> > Thus many DB Ranges can use the same style without having to have any
>> > multiple copies to themselves.
>> That design is overcomplicated and lacks some of the important
>> features. We need at least the following features: two column styles,
>> two row styles, information about header row, total row, column
>> labels, ... Please have a look at Excel to see some of the information
>> we need to store in data structures. A good starting point for the
>> design is to list all the information we need to store for each table.
>> Starting with the list we will then decide for each information how to
>> represent it and how they interact and influence each other.
>> Just a short note: When you think about styles in Calc's core
>> implementation please always think only about the style name.
>> Everything that is hidden behind ScDocument should at least for you
>> only use the style name and never the ScStyleSheet object. If there is
>> ever a case where we need access to the full style we will need to
>> look closer into it.
>> > Row Formatting Core:
>> > The row formatting core is composed of the modifications needed in
>> > itself to support the new alternating colour functionality.
>> > ScDBData will have a new method GetRowFormatting() just like the one in
>> > conditio.cxx (GetData()); however this will return a
>> > object.
>> > The rendering half will have to iterate over each row of the the range
>> > iterating over the ScDBRowFormat items in the container in
>> > instance taking care of the band size of each and thus applying it to
>> > row cells accordingly. This makes the rendering code a little more
>> > complicated as multiple styles have to be related to different rows.
>> > Events (not actually events) in ScDBData such as:
>> > UpdateMoveTab - changes the table
>> > UpdateReference()
>> > ExtendDataArea - extends/shrinks the area under ScDBData
>> Don't worry about them right now. We will come back to them when we
>> have implemented all the data structures and the import/export.
>> > make changes to the structure and coverage of the defined database
>> range. We
>> > need to take care of such events that may wipe out or add newer rows to
>> > range. Such updates set the bModified bool in ScDBData, this needs to be
>> > known and be handled by the rendering half of this feature.
>> > The rendering end:
>> > This rendering end is the something I am discovering with each passing
>> > Not much to write here.
>> > Some design issues:
>> > I see one big problem with the way this are laid out now. The formatting
>> > information and ScDBData's bounds (i.e its rows) are very decoupled. It
>> > becomes the job of the rendering end to apply the correct formatting by
>> > iterating over the ScDBRowFormatting container and getting the
>> > objects taking care of their band sizes as it moves over each row
>> adding in
>> > the formatting information.
>> > This makes the rendering end very complicated (maybe). Since rendering
>> > not just taking the concerned rows and style and shoving in the
>> > One way out can be having a member function in ScDBData that returns an
>> > array of size[No.OfRows], each entry containing the applicable
>> > for that row. This shifts the 'making sense of' part, out of the
>> > part.
>> Don't think about the rendering right now. This will be much simpler
>> than you expect and all most of the logic that you think belongs into
>> the rendering part actually is part of the mode and we will need it
>> also for other parts of the mode implementation. In the end we will
>> just have a method that returns the style name for a cell and not much
>> more. But please don't worry about that right now because in the end
>> you'll see that this will look just natural after all other parts are
>> > [UI Stuff]
>> > Speaking of what to call this functionality and where to place it in the
>> > menu hierarchy:
>> > Either we can:
>> That is even one step past the implementation of the rendering. We'll
>> work with the UX team when we are ready to come up with a mock-up for
>> the UI parts.
>> > Greet the user with the same dialog as seen in Calc's Data->Select
>> > from where the user selects a range to be formatted as table i.e,
>> > alternately.
>> > Or, since clicking format as table option in MS Excel marks a bunch of
>> > as a table with a name, which 'optionally' can be coloured; we will
>> need to
>> > incorporate the alternate colouring option in the Data -> Define Range
>> > dialog in its 'more' section.
>> > In any case once this option is clicked, the user must define a custom
>> > design or choose from a few existing ones, just like in Excel.
>> So let us split the task into several smaller steps that we tackle and
>> where you should not worry about the next step.
>> 1.) Model data structures
>> 2.) Import/export (OOXML and ODF)
>> 3.) Rendering and user interaction
>> 4.) UI
>> So for now we concentrate on how to implement all the model data
>> structures. Mainly how we can represent all the information we need in
>> calc's core implementation and let them work together. As first step
>> please list all the information we need to store in the model and we
>> will discuss on IRC how to represent them.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LibreOffice