Customizable Print Formats GSoC 2015

[Lubomir I. Ivanov]

On 18 March 2015 at 23:22, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
> Hello Lubomir,
>
> I am attaching a draft of my proposal in pdf format, Please review it.
> your feedback is most welcome :)

Gehad, your application is very well formed.
other students can take this into account when they write their own
applications.

here are some entry level notes and questions that will emphasize on
eventual topics of interest for the *actual* user base.

> Pre Existing layouts technical information
> ● Supported Paper size : A4 – A5
> ● Supported Quality : 300 dpi
> ● Supported Orientation : Portrait

we need to extract settings from the QPrinterDialog and from the user
configuration QSettings and adjust the CSS ".media" related sections
before the pagination.
i'm pretty sure this is doable.

> III. Design

solid ideas. we may have to adjust the naming of the classes slightly
(e.g. just Printer instead of CustomPrinter), but we also have to
consider the support for social networks, related class names and to
plan the class inheritance.

> Grantlee templates
> This are the pre­existing templates that can be used directly.

yes, keeping the current templates is nice.

> Figure(3.1) Printing block diagram

the graph looks good. if can you visualize what i mean by the above
comment about QPrinterDialog, basically the CSS / HTML will be fed
(e.g. with search-and-replace amends) with stored settings in the user
configuration (from QSettings) and also with on-the-spot configuration
such as margins, orientation etc. from the QPrinterDialog, then
QPrinter will receive the rendered result as a paint device.

> Rendering the QWebView will take place by scrolling the QPainter viewport over the
> whole content as shown in Figure(3.2)

hmm, when i experimented with a paginated CSS template there was no
need to scroll the viewport and QWebView simply, magically paginated
my pages with render().
i may be missing something, but if you think that the viewport
rendering is better i'm glad to hear why?

> The proposed new dialog figure(3.4)

nice, in general this is the idea about the new dialog.
user suggestions are welcome about this one.

> Template options

the 3 tabs cover what is required pretty much.
how do you plan to generate the previews BTW e.g. QWebView rendering
some sort of default contents on a QPixmap that is placed in the
dialog?

user suggestions are welcome about the layout and functionality
listing of the dialog.

> General
> user can choose paper size, printing quality, margin size.

all of these seem fine to be on the rendered side (e.g. Chrome has
them), but if the user chooses something from the printer dialog
(lower level - read closer to the OS and hardware) we may have to
override some of them with or without notification.

> Style
> user can control the font, font size, and colors.
> random color generator can be included.

nice. users will surely voice about more things in here.
we should keep this tab's contents to a minimum at first, but best
would be to consider a QScrollArea, just in case, as the CSS
flexibility will open more feature requests.

there are two options here. the contents of this tab:
1) should make sense for any possible template.
2) will update based on what is copy-pasted in the next tab

option 1) is much easier as we don't have to deal with the dynamic
creation of Qt UI.
we may have to discuss this further. but i would say, consider 1) for now...

> Template
> this will add the ability to change the source code of the template, this will provide very
> advanced customization and the ability to change where and how does the data
> appear.

an "update" button will be needed to re-visualize the theme in the preview.

> 1 dive per page
> 2 dives per page
> 4 dives per page
> Flow layout
> Column flow layout

i'm sure "Flow layout" and "Column flow layout" will be good examples
for what is possible with the new template stack.

> A. Milestones
> B. Timeline

it's up to you how you are going to plan your work.

here is how i will proceed, but i don't want to change your planned
workflow much:
i would start by cleaning absolutely *all* details on the UI part,
which is usually the most demanding and pretentious part - i.e. there
are users involved :-).

then, i would sit for a while and think of how i'm going to organize
all the functionality in terms of code, naming, classes, inter-module
communication and so on.
(keep in mind we also have to safely remove the current printer
related classes).

starting with Grantlee backend seems about right. i would feed it with
some basic templates, until the QWebView renderer part is done.
only at that point i would start implementing some of the templates
and the UI changes.

> VII. Documentation
> A. User-Manual
> I ll document the new printing features in the user manual.
> B. Online tutorial
> I will write an online tutorial (may be on subsurface­divelog.org ) to describe
> how to create a new template and use it with subsurface printing module from
> scratch.

that would be much appreciated.

-------------------------

this thread and the planned features are open for discussion.
thank you for the application, Gehad. nicely done.

lubomir
--