On 20 March 2015 at 17:06, Gehad Elrobey <gehadelro...@gmail.com> wrote:
> On Fri, Mar 20, 2015 at 2:43 AM, Lubomir I. Ivanov <neolit...@gmail.com>
> wrote:
>> On 18 March 2015 at 23:22, Gehad Elrobey <gehadelro...@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.
>>
>
> My intention was to extract the settings from the QPrintDialog and
> save the user preferences as QSettings, but I think we have to put
> some constraints on the resolution (page size and Dpi ) and the page
> orientation to produce good quality templates that are able to make
> use of the paper area, for sure this constraints can be extended by
> writing additional templates, so I think this constraints are on the
> templates I am planing to develop in the scope of the project only.
>
i don't think the page size should be hardcoded per template or
constrained (as long as the dimensions don't reach the 32bit integer
cap or something like that).
from my tests if i simply modify the CSS the resulted pages were exact
fit to a certain page size (e.g. A2 ) when printed and the HTML layout
adapted quite well.
the available space for a page in QPrinter is just numbers, you *can*
adapt your layout to fit on it. the current printer implementation
does exactly that.
say, if the CSS is in a QString after the user has made his picks, we
can search-and-replace certain variables.
for instance like SSRF_PAGE_W, SSRF_PAGE_H, SSRF_MARGIN:
@page {
size: SSRF_PAGE_W SSRF_PAGE_H;
margin: SSRF_MARGIN;
}
for A4:
SSRF_PAGE_W becomes "21cm"
SSRF_PAGE_H becomes "29.7cm"
(for landscape the reverse happens.)
SSRF_MARGIN becomes for instance "1cm"
...or instead of these variables, we can keep some default values so
that the CSS is not invalid and do some smarter search-and-replace.
only once the CSS is adapted to the user preferences we feed it to the
HTML, load the HTML in QWebView and render it.
do you see any problems with these ideas?
>>> 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.
>>
>
> Yes, I think Grantlee can take care of that. I will add this to the
> block diagram.
>
related to the commend from above.
>>> 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?
>>
>
> When I use QWebFrame::render() I got the first page only rendered so I
> used QWebFrame::scroll() , anyway I didn't test this well I will have
> a deeper look into this.
>
my mistake; i've used:
someWebView->print(&somePrinter);
and it printed all pages, but i'm not sure if this is the way to go as
it prints directly, while we also need to overlay the profiles.
render(), scroll() and a viewport might be the way to go.
>>> 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?
>>
>
> I think the QWebView will render the actual HTML page that will be
> printed, so the user can preview the style changes dynamically (I am
> not sure how doable is this)
>
but if there are no dives in the list, no data will be available to be printed.
falling back to some default / mockup contents or always using them is
the option i recommend.
this way, for no dives in the list, the user can still go in the print
dialog, modify and store his template while previewing a mockup.
lubomir
--
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
