Customizable prints progress

[Lubomir I. Ivanov]

On 9 August 2015 at 18:23, Gehad Elrobey <gehadelrobey at gmail.com> wrote:
> Hey, Lubomir.
>
>> i'm getting some errors:
>> templatelayout.cpp:310:6: error: redefinition of 'void Dive::put_tags()'
>>
>> same for:
>> ::put_sac()
>> ::put_gas()
>>
>> removing the duplicates in the .cpp solves the issue.
>>
>
> where are the duplicates? I can't find any.

ok, this has to be some strange merge error in GIT (mine is a bit outdated).
i pulled again and the function duplicates are gone. weird...

looks like an error on my end. ignore.

>> > For some reasons the view width ratio "0.1vw" is not calculated, so the
>> > value assigned is always 1px border which appears to be thick in low
>> > resolution prints and small paper sizes, while it is so thin in high
>> > resolution/ large paper sizes (eg. A0).
>> >
>> > I don't know why "vw" sizing is not working as supposed with
>> > border-width in
>> > QWebView though it works correctly for me in Chromium & Firefox.
>>
>> "vw" seems to be (used to be) buggy in most browsers.
>> but having no support for the table border width is quite bad. :\
>>
>> what alternatives do we have? can we dynamically adjust the user value
>> in the templates based on the selected printer DPI or something?
>>
>
> Yes, we can dynamically adjust the border-size. We can also use Javascript
> to calculate the needed border-size (I was avoiding to used any javascript
> code in the templates as I believe it will slow down the rendering). The
> third option depends mainly on HTML/CSS is to use external div that works as
> the border to our div, AFAIK "vw" works correctly with div sizes.
>

i'm not very savvy in these parts, but we kind of need the border
adjustment as someone will soon ask "why doesn't it work?".
i don't like the JS option in particular. if "vw" works with div tags,
that might be the best option, but i'm not sure, so please use the
best option possible.

hopefully this is the only CSS issue in WebKit that we will encounter
(unlikely)...

>> > I guess I fixed all the remaining issues, and pushed them to my branch,
>> > please check them and update me if I got any of them incorrectly. I also
>> > added a simple statistics view and some other bug fixes.
>>
>> for the statistics type of print, i think we need use a new set of
>> templates.
>> so, if the user selects "Statistics" the combo box in "Template" needs
>> to be re-filled with a different list.
>>
>> perhaps a couple of folders in printing_templates need to be used for
>> that:
>> "divelist"
>> "statistics"
>>
>> in general, i'm not sure how the "Stats" print is going to work. if
>> it's only going to use one template then we need to disable the Import
>> / Export and so on.
>> if it can support multiple templates then the combo box makes sense, i
>> guess.
>>
>
> I thought of adding different templates for the statistics view, This will
> require to export the statistics data structures to Grantlee backend, Which
> I think will over complicate the printing stack for no actual use-case. So
> we may need to ask the community for feedback, if adding customized
> templates for printing statistics is usable feature or not? if not we can
> disable the combo box and the useless ui elements.

let's do the following, but please move this one as low-priority for GSoC:
- support only a single template for the stats
- the combobox will be disabled but will show the text "Default"
- Edit will be enabled
- let's make this template look close to what we have in the "Table"
template visuals wise
- this bundled template will still support the colors and fonts (?)
- Import/Export/Delete will be disabled

what do you think? is it doable?
if at some point users say "can we have *more* in the stats print", we
can think of possible solutions.

>
>>
>> >
>> > Now I will work mainly on fixing the page scrolling bug and the
>> > documentation until you update me with further fixes/enhancements.
>> >
>>
>> what is the "scrolling bug"?
>>
>
> This bug happens in "table" and "flowlayout" templates, it takes place when
> the size of the full web view to be rendered is not divisible by the size of
> the view port (Page size), Please check "scrolling_bug.jpg" for
> illustration.
>
> Rendering the web view is completed by scrolling the view port over the web
> page, after rendering each page QPrinter::newPage() and
> QWebView:ScrollDown() are called, the incorrect behavior takes place in the
> last page when the actual scrolled down distance is smaller than the full
> page size, so there is some area (colored by red in the illustration image)
> that is rendered twice on the two last pages.
>

ok, i'm sure this is solvable.

> I added the rest of your notes to my to do list, and will update you with my
> progress.

thank you.

lubomir
--