Re: Customizable Print Formats GSoC 2015
On Fri, Mar 20, 2015 at 5:59 PM, Lubomir I. Ivanov neolit...@gmail.com wrote:
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?
No, I ll add this into the proposal, thanks for the clarification.
I also wanted to suggest the idea of printing dive photos may be on
glossy paper, I don't know if this use-case may be interesting to
someone?
--
regards,
Gehad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
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
Re: Customizable Print Formats GSoC 2015
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. 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. 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. 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) 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. Save and Discard buttons are missing too, I missed those in the prototyping :) 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. I will edit this part of the proposal as you suggested and resend it again. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
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. 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 preexisting 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 subsurfacedivelog.org ) to describe how to create a new template and use it with subsurface printing module from scratch. that would be much
Re: Customizable Print Formats GSoC 2015
On 10 March 2015 at 17:49, Gehad Elrobey gehadelro...@gmail.com wrote: On Sun, Mar 8, 2015 at 9:40 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: compared to what we do ATM - rendering the profile QWidget directly to QPrinter which produces vector (Win32 / OSX only), the introduction of SVG which is grabbed from a QWidget then displayed in QWebView which is then rendered to QPrinter surely will slow things down as it introduce an intermediate step (SVG). the alternative - somehow obtain the absolute position of the div (jQuery?) where the profile should be located and it's scaled dimensions on the page and then do QProfileWidget-render() at that exact location on top of the already rendered HTML template. this avoids SVG completely! After I gave QWebView some tests I was able to render a QPicture on the top of the QWebView in the area of the dive profile. Getting the dive profile box location wasn't hard as I used QWebFrame::findAllElements() so I even didn't use javascript or JQuery. awesome, Also by using our own rendering we will be able to provide printing with different qualities (DPIs) as an option, but we will lose some printing features that WebKit provides in its printing approach QWebFrame::print() ex. @media print page-break-inside so we will need to handle the pagination on our own. again this is the solution i think is the correct one, to avoid SVG. if we have way to much trouble with this second pass (layouting the profiles on top of the pages), SVG is there as the backup plan. I attached a pdf printout of the QWebview rendering the HTML template and a QPicture rendered on top. it seems to offset the profile QPicture a little vertically for each page (moves it little above of the designated area), which could be a rounding error. hopefully fixable by something like qRound() on our side. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
I've only really scanned this thread, so please excuse me if I'm raising something that's already been covered. It seems we're talking about rendering using HTML along with a few other things. Have we considered pagination? I know this is something that HTML isn't great at. You can, of course, print html, and it will paginate it, but is controlling how this happens easy? I understand there is support for pagination in CSS - is this enough for us to do reasonable looking 1 dive per page, 2 dives per page, etc? Or, are we considering rendering each dive as an individual HTML document, and then have the framework code assemble that into a pdf/print commands, etc? One of the reasons i raised this as a possible GSoC project was the poor experience when you have any more than a few lines of 'prose' in the notes for a dive - I tend to waffle a bit in some of my dive logs. Martin ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On Tue, Mar 10, 2015 at 1:20 AM, Long, Martin mar...@longhome.co.uk wrote: I've only really scanned this thread, so please excuse me if I'm raising something that's already been covered. It seems we're talking about rendering using HTML along with a few other things. Have we considered pagination? I know this is something that HTML isn't great at. You can, of course, print html, and it will paginate it, but is controlling how this happens easy? I understand there is support for pagination in CSS - is this enough for us to do reasonable looking 1 dive per page, 2 dives per page, etc? CSS supports 'page-break-inside' property which define whether a page break is allowed inside a specified element or not, also max/min height can be used for pagination, but taking into consideration that the overflow of long notes will either be trimmed or will expand the dive to more printing area and in this case we can't ensure to have N dives per page (this can be something like flow layout). So as I expect yes we can control this easily. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 8 March 2015 at 20:55, Gehad Elrobey gehadelro...@gmail.com wrote: Thanks lubomir for your clarification. When I tested rendering some svg images with QWebView it wasn't slow at all. So the bottleneck in this process is saving QPicture as SVG? compared to what we do ATM - rendering the profile QWidget directly to QPrinter which produces vector (Win32 / OSX only), the introduction of SVG which is grabbed from a QWidget then displayed in QWebView which is then rendered to QPrinter surely will slow things down as it introduce an intermediate step (SVG). the alternative - somehow obtain the absolute position of the div (jQuery?) where the profile should be located and it's scaled dimensions on the page and then do QProfileWidget-render() at that exact location on top of the already rendered HTML template. this avoids SVG completely! i would like us to test the alternative firs, unless you have objections. surely this won't be that difficult with Javascript / CSS / jQuery: http://stackoverflow.com/questions/683339/how-do-i-find-the-absolute-position-of-an-element-using-jquery if it's way too tricky we can go back to the SVG idea. Also we don't have to save the svg images to the disk and render them back to QWebView, I found that we can access the QWebView requests directly by extending QNetworkAccessManager class and overridding createRequest() function, Then we can serve the meta:image/svg requests directly from memory. do you think this will do any optimization? i don't think QNetworkAccessManger is needed as we can use QBuffer. see my example a couple of emails above: QByteArray byteArray; QBuffer buffer(byteArray); QSvgGenerator svg; svg.setOutputDevice(buffer); ... lubomir -- P.S.: bottom-posting please :-) ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
Thanks lubomir for your clarification. When I tested rendering some svg images with QWebView it wasn't slow at all. So the bottleneck in this process is saving QPicture as SVG? Also we don't have to save the svg images to the disk and render them back to QWebView, I found that we can access the QWebView requests directly by extending QNetworkAccessManager class and overridding createRequest() function, Then we can serve the meta:image/svg requests directly from memory. do you think this will do any optimization? On Sun, Mar 8, 2015 at 12:46 AM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 8 March 2015 at 00:23, Gehad Elrobey gehadelro...@gmail.com wrote: On Sun, Mar 8, 2015 at 12:11 AM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 7 March 2015 at 23:47, Lubomir I. Ivanov neolit...@gmail.com wrote: one thing to figure out is how are we going to embed the profile pictures... if we are capturing the output of a QWebPage then we first need to show the profiles in there. for that img src=data: metatype, base64, theDataGoesHere / can be used. now, there is an alternative for all that, but it's tricky... since we can use QWebFrame::render() on a QPainter that uses the QPrinter as paint device, in theory we can position a QPicture of the profile exactly over the already rendered profile HTML frame (e.g. in your PDF that would be dive profile area), but that's only in theory. I was thinking of using Grantlee to generate parts of the HTML code, one part for each widget that will be placed in the layout dynamically, we can also insert the profile photos dynamically as the HTML code. So the Qt class will call Grantlee many times to fill in the div s (or widgets in the main layout) dynamically and generate the full html code that can be rendered by QWebPage and printed. if i understand correctly you are planning to load the profiles as images in HTML and render both the dive data and the profile as a whole, via QWebPage. is that the case? but i think that for vector profiles in the printout to work, we need to use meta:image/svg instead of meta:image/png and that's why i proposed QSvg. we currently have the profile printed as vector (on Windows at least), so going back to strictly raster profiles in the printout is a step backwards. but if there is a way to avoid showing SVG in the HTML that would be the way to go, because it's going to be very slow. as i explained above, it will require some trickery (CSS?) to obtain the absolution position of where the profile has to be inserted on the page and it's dimensions. if we can estimate that, we can simply render a profile as QPicture over the HTML rendered layout (QPrinter being the paint device for both the underlying HTML template and the profiles which will be placed on top). lubomir -- -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On Sun, Mar 8, 2015 at 12:11 AM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 7 March 2015 at 23:47, Lubomir I. Ivanov neolit...@gmail.com wrote: one thing to figure out is how are we going to embed the profile pictures... if we are capturing the output of a QWebPage then we first need to show the profiles in there. for that img src=data: metatype, base64, theDataGoesHere / can be used. now, there is an alternative for all that, but it's tricky... since we can use QWebFrame::render() on a QPainter that uses the QPrinter as paint device, in theory we can position a QPicture of the profile exactly over the already rendered profile HTML frame (e.g. in your PDF that would be dive profile area), but that's only in theory. I was thinking of using Grantlee to generate parts of the HTML code, one part for each widget that will be placed in the layout dynamically, we can also insert the profile photos dynamically as the HTML code. So the Qt class will call Grantlee many times to fill in the div s (or widgets in the main layout) dynamically and generate the full html code that can be rendered by QWebPage and printed. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 8 March 2015 at 00:23, Gehad Elrobey gehadelro...@gmail.com wrote: On Sun, Mar 8, 2015 at 12:11 AM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 7 March 2015 at 23:47, Lubomir I. Ivanov neolit...@gmail.com wrote: one thing to figure out is how are we going to embed the profile pictures... if we are capturing the output of a QWebPage then we first need to show the profiles in there. for that img src=data: metatype, base64, theDataGoesHere / can be used. now, there is an alternative for all that, but it's tricky... since we can use QWebFrame::render() on a QPainter that uses the QPrinter as paint device, in theory we can position a QPicture of the profile exactly over the already rendered profile HTML frame (e.g. in your PDF that would be dive profile area), but that's only in theory. I was thinking of using Grantlee to generate parts of the HTML code, one part for each widget that will be placed in the layout dynamically, we can also insert the profile photos dynamically as the HTML code. So the Qt class will call Grantlee many times to fill in the div s (or widgets in the main layout) dynamically and generate the full html code that can be rendered by QWebPage and printed. if i understand correctly you are planning to load the profiles as images in HTML and render both the dive data and the profile as a whole, via QWebPage. is that the case? but i think that for vector profiles in the printout to work, we need to use meta:image/svg instead of meta:image/png and that's why i proposed QSvg. we currently have the profile printed as vector (on Windows at least), so going back to strictly raster profiles in the printout is a step backwards. but if there is a way to avoid showing SVG in the HTML that would be the way to go, because it's going to be very slow. as i explained above, it will require some trickery (CSS?) to obtain the absolution position of where the profile has to be inserted on the page and it's dimensions. if we can estimate that, we can simply render a profile as QPicture over the HTML rendered layout (QPrinter being the paint device for both the underlying HTML template and the profiles which will be placed on top). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On Mar 6, 2015, at 7:15 AM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 6 March 2015 at 16:37, Dirk Hohndel d...@hohndel.org wrote: No, we will not include TeX or assume that is installed. I see the technical benefit, it's completely unrealistic as print backend for a dive log app i agree, Robert, if you want, you can still add the Export to TeX feature from the export dialog which would be nice. Our user base will not have TeX installed. I’ll bet my lunch money on that. Cluttering our UI for something that no one will use? Questionable. Worse, people will insist that the Linux packages depend on TeX and install another 280MB of crap, just in case someone might at some point want to print a logbook. Sorry, NAK from the maintainer. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 6 March 2015 at 11:31, Anton Lundin gla...@acc.umu.se wrote: On 06 March, 2015 - Robert Helling wrote: Hi, On 06.03.2015, at 00:52, Gehad Elrobey gehadelro...@gmail.com wrote: I managed to print a QTextDocument directly after generating the HTML code by Grantlee with Qt5. I attached a pdf of the print out. as I said, my worry is not so much that you can use templates to generate some html. I am concerned that the Qt subset of html is not expressive enough to produce decent layouts beyond simple tables. To get an idea what people’s paper divelogs look like in the wild, do a google image search for “dive log template”. Compared to what we have now, we need much better control over spacing (inclunding whitespace, there we currently waste far too much precious room on the paper), fields for which we don’t have information should in many cases not be displayed and the room be used for what we actually have etc. For me, for example, beyond the very basic information (date, depth, time, location, buddy), the notes are by far the most important textual element and should occupy sufficient room (in a decent font size). As far as i can understand http://qt-project.org/wiki/QtWebEngine , Qt's html renderer is based on chromium so i don't think its lacking any bells and whistles. TMK there are a couple of engines. there is one which is used by QTextDocument, which is a HTML subset and lacks at certain areas like CSS, and the other one is the WebKit engine which is like the backend of a full-blown modern browser. like i said in the previous email, i'm pretty sure we are going to need WebKit, because QTextDocument is going to soon become sub-par for our needs, which opens two questions: - how fast is the WebKit rendering to QPicture / QPixmap? - do we care that the Windows package is going to inflate 30+MB for the release build (also it's probably going to require ICU which is another 20+MB unless there is a way to use WebKit without ICU)? lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On Mar 6, 2015, at 3:29 AM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 6 March 2015 at 13:13, Robert Helling hell...@atdotde.de wrote: On 06.03.2015, at 10:31, Anton Lundin gla...@acc.umu.se wrote: As far as i can understand http://qt-project.org/wiki/QtWebEngine , Qt's html renderer is based on chromium so i don't think its lacking any bells and whistles. I am glad to hear that. Still we need it to describe a printed page rather (with elements to grow/shrink to fit paper sizes etc) than an page in a web browser. As a start, I just tried to produce some simple example with LibreOfficeWriter and save that as html but the output is not even close to the way the document looked. yeah, HTML is really only well fit for web browsers and as everyone knows when you print a web-page it may look *a bit* different in terms of layout / scaling etc. we are going to need some experiments with Grantlee and a renderer (e.g. WebKit) to see to what extent we can get it to be WYSIWYG. That, to me, is the way to go. It might not be pixel perfect rendering. But we should be able to get something that gets people roughly what they want. I made this a GSoC idea for a reason. This is perfect for a student to work on. The underlying programming and tools are not too complicated, the math / logic is not too complicated, but it will take patience and some trial and error to get this mostly right. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 6 March 2015 at 17:20, Dirk Hohndel d...@hohndel.org wrote: On Mar 6, 2015, at 3:29 AM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 6 March 2015 at 13:13, Robert Helling hell...@atdotde.de wrote: On 06.03.2015, at 10:31, Anton Lundin gla...@acc.umu.se wrote: As far as i can understand http://qt-project.org/wiki/QtWebEngine , Qt's html renderer is based on chromium so i don't think its lacking any bells and whistles. I am glad to hear that. Still we need it to describe a printed page rather (with elements to grow/shrink to fit paper sizes etc) than an page in a web browser. As a start, I just tried to produce some simple example with LibreOfficeWriter and save that as html but the output is not even close to the way the document looked. yeah, HTML is really only well fit for web browsers and as everyone knows when you print a web-page it may look *a bit* different in terms of layout / scaling etc. we are going to need some experiments with Grantlee and a renderer (e.g. WebKit) to see to what extent we can get it to be WYSIWYG. That, to me, is the way to go. It might not be pixel perfect rendering. But we should be able to get something that gets people roughly what they want. I made this a GSoC idea for a reason. This is perfect for a student to work on. The underlying programming and tools are not too complicated, the math / logic is not too complicated, but it will take patience and some trial and error to get this mostly right. any comments on my idea earlier in this thread to expose the Grantlee templates per dive as a backend so that both for the social network share and the printing can use them? it complicates things and goes outside of the GSoC printing idea scope, though. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 6 March 2015 at 12:52, Robert Helling hell...@atdotde.de wrote: Hi, On 06.03.2015, at 11:47, Lubomir I. Ivanov neolit...@gmail.com wrote: - what are going to present to the user in terms of UI / dialogs etc, i assume we can start with a text box for the Grantlee template generator input we could as well produce a hand-full of standard layout (“themes” if you like) and let the user choose from those. If they want anything different or change those, they would have to add templates (with a text editor or whatever). I think that would be good enough for must users. yes, that's the better of ideas, i think. for instance, 4 built-in templates and a text box to paste-in a user defined one. ..and we can also attempt to have some toggle buttons for the default templates (e.g. profile on top/bottom) to provide some extra customization for users who can't write their own template. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 06 March, 2015 - Robert Helling wrote: Hi, On 06.03.2015, at 00:52, Gehad Elrobey gehadelro...@gmail.com wrote: I managed to print a QTextDocument directly after generating the HTML code by Grantlee with Qt5. I attached a pdf of the print out. as I said, my worry is not so much that you can use templates to generate some html. I am concerned that the Qt subset of html is not expressive enough to produce decent layouts beyond simple tables. To get an idea what people’s paper divelogs look like in the wild, do a google image search for “dive log template”. Compared to what we have now, we need much better control over spacing (inclunding whitespace, there we currently waste far too much precious room on the paper), fields for which we don’t have information should in many cases not be displayed and the room be used for what we actually have etc. For me, for example, beyond the very basic information (date, depth, time, location, buddy), the notes are by far the most important textual element and should occupy sufficient room (in a decent font size). As far as i can understand http://qt-project.org/wiki/QtWebEngine , Qt's html renderer is based on chromium so i don't think its lacking any bells and whistles. //Anton -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 6 March 2015 at 13:13, Robert Helling hell...@atdotde.de wrote: On 06.03.2015, at 10:31, Anton Lundin gla...@acc.umu.se wrote: As far as i can understand http://qt-project.org/wiki/QtWebEngine , Qt's html renderer is based on chromium so i don't think its lacking any bells and whistles. I am glad to hear that. Still we need it to describe a printed page rather (with elements to grow/shrink to fit paper sizes etc) than an page in a web browser. As a start, I just tried to produce some simple example with LibreOfficeWriter and save that as html but the output is not even close to the way the document looked. yeah, HTML is really only well fit for web browsers and as everyone knows when you print a web-page it may look *a bit* different in terms of layout / scaling etc. we are going to need some experiments with Grantlee and a renderer (e.g. WebKit) to see to what extent we can get it to be WYSIWYG. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
http://stackoverflow.com/questions/3341485/how-to-make-a-html-page-in-a4-paper-size-pages Em Sex, 6 de mar de 2015 08:36, Gehad Elrobey gehadelro...@gmail.com escreveu: On Fri, Mar 6, 2015 at 1:29 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 6 March 2015 at 13:13, Robert Helling hell...@atdotde.de wrote: On 06.03.2015, at 10:31, Anton Lundin gla...@acc.umu.se wrote: As far as i can understand http://qt-project.org/wiki/QtWebEngine , Qt's html renderer is based on chromium so i don't think its lacking any bells and whistles. I am glad to hear that. Still we need it to describe a printed page rather (with elements to grow/shrink to fit paper sizes etc) than an page in a web browser. As a start, I just tried to produce some simple example with LibreOfficeWriter and save that as html but the output is not even close to the way the document looked. yeah, HTML is really only well fit for web browsers and as everyone knows when you print a web-page it may look *a bit* different in terms of layout / scaling etc. we are going to need some experiments with Grantlee and a renderer (e.g. WebKit) to see to what extent we can get it to be WYSIWYG. I am think of making some default layouts that divide the page into N x M boxes (in different page orientation) , and the user have the option to map the data to the boxes for each dive. for example he puts the dive profile in the top right corner and the dive notes in the bottom of the page and this layout is repeated for each dive. The problem of well fitting can be handled by responsive html design for each widget so that the data will always fit in the widget that is placed in the N x M boxes. This will need a lot more testing to check how this will actually work. lubomir -- -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 6 March 2015 at 13:36, Gehad Elrobey gehadelro...@gmail.com wrote: I am think of making some default layouts that divide the page into N x M boxes (in different page orientation) , and the user have the option to map the data to the boxes for each dive. for example he puts the dive profile in the top right corner and the dive notes in the bottom of the page and this layout is repeated for each dive. The problem of well fitting can be handled by responsive html design for each widget so that the data will always fit in the widget that is placed in the N x M boxes. This will need a lot more testing to check how this will actually work. the current printlayout.cpp supports NxM (even if the UI only allows certain ones). there is simple formula that is used for that. basically it takes the N and M parameters and based on the available space on the page and padding it estimates the size of single dive (profile + table). the problem with this approach is that if, say the dive notes are too long they may not fit in the singular estimated space for a dive. the alternative is to feed only N (e.g. columns) and produce a more fluid layout where a dive can span vertically even to multiple columns if it has longer notes. the next dive starts at the column where the previous one ended (think newspaper). lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On Thu, Mar 5, 2015 at 6:55 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 4 March 2015 at 16:31, Tomaz Canabrava tcanabr...@kde.org wrote:
On Wed, Mar 4, 2015 at 11:14 AM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 4 March 2015 at 16:05, Tomaz Canabrava tcanabr...@kde.org wrote:
also, i don't understand Tomaz' idea about the Grantlee extension, so
perhaps we need to investigate into that as well.
it probably uses QTableView Qt's Model-View-X pattern, which i don't
like that much, yet Subsurface already uses it pretty much
everywhere!
Grantlee *is* a HTML + CSS template engine that integrates with Qt.
it follows Django template scheme, so it's very flexible and easy to
extend
yep, i did gather that previously.
for instance, we could do something like this in grantlee:
template.html
header ... /header
body
h1 {{ dive.where }} /h1
h2 {{ dive.buddy }} /h2
/body
( yes, very short example )
and let the grantlee template system do it's magic.
i don't understand what the output of Grantlee template generator is;
is it a data model for a QTableView that then can be rendered to an
image, is it an image, or something else?
an html file. nothing more than this.
so for the built-in printing, i assume we need to load the file (/text
?) into a rendering entity like QTextDocument or QWebPage and then
produce a QPicture / QPixmap that can be fed to QPrinter?
do you think that QTextDocument will suffice or WebKit will be needed?
from what i tested at some point the built-in HTML subset wasn't
optimal for more complicated input.
lubomir
--
I managed to print a QTextDocument directly after generating the HTML code
by Grantlee with Qt5.
I attached a pdf of the print out.
--
regards,
Gehad
print.pdf
Description: Adobe PDF document
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 4 March 2015 at 16:31, Tomaz Canabrava tcanabr...@kde.org wrote:
On Wed, Mar 4, 2015 at 11:14 AM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 4 March 2015 at 16:05, Tomaz Canabrava tcanabr...@kde.org wrote:
also, i don't understand Tomaz' idea about the Grantlee extension, so
perhaps we need to investigate into that as well.
it probably uses QTableView Qt's Model-View-X pattern, which i don't
like that much, yet Subsurface already uses it pretty much everywhere!
Grantlee *is* a HTML + CSS template engine that integrates with Qt.
it follows Django template scheme, so it's very flexible and easy to
extend
yep, i did gather that previously.
for instance, we could do something like this in grantlee:
template.html
header ... /header
body
h1 {{ dive.where }} /h1
h2 {{ dive.buddy }} /h2
/body
( yes, very short example )
and let the grantlee template system do it's magic.
i don't understand what the output of Grantlee template generator is;
is it a data model for a QTableView that then can be rendered to an
image, is it an image, or something else?
an html file. nothing more than this.
so for the built-in printing, i assume we need to load the file (/text
?) into a rendering entity like QTextDocument or QWebPage and then
produce a QPicture / QPixmap that can be fed to QPrinter?
do you think that QTextDocument will suffice or WebKit will be needed?
from what i tested at some point the built-in HTML subset wasn't
optimal for more complicated input.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
so for the built-in printing, i assume we need to load the file (/text ?) into a rendering entity like QTextDocument or QWebPage and then produce a QPicture / QPixmap that can be fed to QPrinter? do you think that QTextDocument will suffice or WebKit will be needed? from what i tested at some point the built-in HTML subset wasn't optimal for more complicated input. I don't know the answer - I'll talk with the Calligra guys, because they do lots of printing tests and will have a better answer. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On Wed, Mar 4, 2015 at 4:14 PM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 4 March 2015 at 16:05, Tomaz Canabrava tcanabr...@kde.org wrote:
also, i don't understand Tomaz' idea about the Grantlee extension, so
perhaps we need to investigate into that as well.
it probably uses QTableView Qt's Model-View-X pattern, which i don't
like that much, yet Subsurface already uses it pretty much everywhere!
Grantlee *is* a HTML + CSS template engine that integrates with Qt.
it follows Django template scheme, so it's very flexible and easy to
extend
yep, i did gather that previously.
for instance, we could do something like this in grantlee:
template.html
header ... /header
body
h1 {{ dive.where }} /h1
h2 {{ dive.buddy }} /h2
/body
( yes, very short example )
and let the grantlee template system do it's magic.
i don't understand what the output of Grantlee template generator is;
is it a data model for a QTableView that then can be rendered to an
image, is it an image, or something else?
BTW Gehad, if you want, you can start experimenting with Grantlee. I
have it complied on Windows so perhaps you can try setuping a simple
TestGrantlee POC package for Qt5 to show everyone how it fits our
needs?
I built Grantlee on linux and I am going to look more into it these days. I
love the fact that Grantlee produces HTML files that can be printed easily
with neat quality without the need to reinvent the wheel.
I'm -1 for depending on tex because it's a huge package and a mess to
install it on windows
if we can get your idea to work then we can use it for printing, while
the TeX export is still viable as a separate feature.
Quite a lot of the issues we had on the painter side was when we
depended on
Qt4, since now we are depending on qt5 we can look if the issues are
still
happening.
hopefully true.
lubomir
--
--
regards,
Gehad
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 4 March 2015 at 07:52, Gehad Elrobey gehadelro...@gmail.com wrote: On Tue, Mar 3, 2015 at 2:05 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 3 March 2015 at 01:10, Gehad Elrobey gehadelro...@gmail.com wrote: Hi, As Subsurface became a mentoring organization in GSoC '15 so I am willing to join this year under Subsurface organization. I am interested in the idea of Adding customizable print formats. I am specially interested in this idea as subsurface lacks good printing capabilities and also this project will be some how related to the HTML codebase I wrote in my project last year. Before I start writing my proposal I would like to know the community's (and Lubomir for sure as the mentor) opinions and expectations about the project? and what do you think is missing mainly in the current printing system? some random thoughts, i would agree that some research and user feedback is needed here, since as a non-user the current printing capabilities seem static but sufficient to me! the facebook share is even less flexible than what we have for printing. perhaps it's possible to unify the backend for social network share layouting and the print layouting, since doing a printout is probably for the purpose of sharing: In my opinion facebook sharing is limited to show a dive profile (with some dive photos if they exist) and add the remaining data to the photo caption, while printing on the other hand needs to be highly customizable to be able to use every space in the paper. Please correct me if I am wrong(I don't use the feature as a user). at some point facebook users may want a table attached to the profile picture. the caption can cover things like biddies, location etc, but i don't think it's suitable for everything. but if captions in social networks are sufficient for the extra dive data then there is no point of attaching a table to the profile picture. some (questionable) forward thinking in terms of backend. - ShareLayout could be the backend for what i describe - a ShareLayout will determine the social network share or printout layout - having or not having the profile or the table could be a toggle option in ShareLayout - ShareLayoutOptions could be the frontend that the user interacts with and it generates a ShareLayout - the current PrintLayout could arrange ShareLayouts e.g. user defined NxM layouts - the facebook share will upload a single ShareLayout Can you clarify this part more please, I don't get how user data will be mapped to the ShareLayout? ShareLayout is fed dive data (struct dive) and layout data (e.g. HTML). based on that a ShareLayout can render a visual of the provided data. this is something i would do to suit both the social network demands and the print demands. but if the social network backend abstraction is not needed we can rename / adjust the class names. i would ditch the QTablexx implementations completely and implement a custom QPainter that is HTML template based (and probably quite slow). Tomaz at some point proposed a Qt template library for custom printing, but i don't like the idea of adding even more dependencies to Subsurface. if others approve of that, i would do the same. I am interested in using HTML templates that gives high customization to the prints, while the library Tomaz has proposed seems to be very good too. I think we may need Dirk's opinion about the dependency. i've tried compiling the Grantlee on Windows and it works, but i haven't tested it. out of time ATM. this part from the ideas page is important: But the team is open to other ideas that solve the underlying problem: being able to customize the print output to include the information that the user perceives as relevant and giving the user control over major style elements like font sizes and positioning of the various data. i think, before you start writing the proposal users should provide feedback on what level of customization they want from the print layouting. I am going to ask for more user input in subsurface user forum. sounds good. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On Wed, Mar 4, 2015 at 11:14 AM, Lubomir I. Ivanov neolit...@gmail.com
wrote:
On 4 March 2015 at 16:05, Tomaz Canabrava tcanabr...@kde.org wrote:
also, i don't understand Tomaz' idea about the Grantlee extension, so
perhaps we need to investigate into that as well.
it probably uses QTableView Qt's Model-View-X pattern, which i don't
like that much, yet Subsurface already uses it pretty much everywhere!
Grantlee *is* a HTML + CSS template engine that integrates with Qt.
it follows Django template scheme, so it's very flexible and easy to
extend
yep, i did gather that previously.
for instance, we could do something like this in grantlee:
template.html
header ... /header
body
h1 {{ dive.where }} /h1
h2 {{ dive.buddy }} /h2
/body
( yes, very short example )
and let the grantlee template system do it's magic.
i don't understand what the output of Grantlee template generator is;
is it a data model for a QTableView that then can be rendered to an
image, is it an image, or something else?
an html file. nothing more than this.
BTW Gehad, if you want, you can start experimenting with Grantlee. I
have it complied on Windows so perhaps you can try setuping a simple
TestGrantlee POC package for Qt5 to show everyone how it fits our
needs?
I'm -1 for depending on tex because it's a huge package and a mess to
install it on windows
if we can get your idea to work then we can use it for printing, while
the TeX export is still viable as a separate feature.
Quite a lot of the issues we had on the painter side was when we
depended on
Qt4, since now we are depending on qt5 we can look if the issues are
still
happening.
hopefully true.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
Grantlee is a very good library, if we need to suporte custom, user templates, that is the choice to make. Em Ter, 3 de mar de 2015 09:06, Lubomir I. Ivanov neolit...@gmail.com escreveu: On 3 March 2015 at 01:10, Gehad Elrobey gehadelro...@gmail.com wrote: Hi, As Subsurface became a mentoring organization in GSoC '15 so I am willing to join this year under Subsurface organization. I am interested in the idea of Adding customizable print formats. I am specially interested in this idea as subsurface lacks good printing capabilities and also this project will be some how related to the HTML codebase I wrote in my project last year. Before I start writing my proposal I would like to know the community's (and Lubomir for sure as the mentor) opinions and expectations about the project? and what do you think is missing mainly in the current printing system? some random thoughts, i would agree that some research and user feedback is needed here, since as a non-user the current printing capabilities seem static but sufficient to me! the facebook share is even less flexible than what we have for printing. perhaps it's possible to unify the backend for social network share layouting and the print layouting, since doing a printout is probably for the purpose of sharing: - ShareLayout could be the backend for what i describe - a ShareLayout will determine the social network share or printout layout - having or not having the profile or the table could be a toggle option in ShareLayout - ShareLayoutOptions could be the frontend that the user interacts with and it generates a ShareLayout - the current PrintLayout could arrange ShareLayouts e.g. user defined NxM layouts - the facebook share will upload a single ShareLayout i would ditch the QTablexx implementations completely and implement a custom QPainter that is HTML template based (and probably quite slow). Tomaz at some point proposed a Qt template library for custom printing, but i don't like the idea of adding even more dependencies to Subsurface. if others approve of that, i would do the same. this part from the ideas page is important: But the team is open to other ideas that solve the underlying problem: being able to customize the print output to include the information that the user perceives as relevant and giving the user control over major style elements like font sizes and positioning of the various data. i think, before you start writing the proposal users should provide feedback on what level of customization they want from the print layouting. Davide, Robert - any ideas? lubomir -- p.s. please mind there is a chance that i could be AFK for weeks during the GSoC period. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On Tue, Mar 3, 2015 at 2:05 PM, Lubomir I. Ivanov neolit...@gmail.com wrote: On 3 March 2015 at 01:10, Gehad Elrobey gehadelro...@gmail.com wrote: Hi, As Subsurface became a mentoring organization in GSoC '15 so I am willing to join this year under Subsurface organization. I am interested in the idea of Adding customizable print formats. I am specially interested in this idea as subsurface lacks good printing capabilities and also this project will be some how related to the HTML codebase I wrote in my project last year. Before I start writing my proposal I would like to know the community's (and Lubomir for sure as the mentor) opinions and expectations about the project? and what do you think is missing mainly in the current printing system? some random thoughts, i would agree that some research and user feedback is needed here, since as a non-user the current printing capabilities seem static but sufficient to me! the facebook share is even less flexible than what we have for printing. perhaps it's possible to unify the backend for social network share layouting and the print layouting, since doing a printout is probably for the purpose of sharing: In my opinion facebook sharing is limited to show a dive profile (with some dive photos if they exist) and add the remaining data to the photo caption, while printing on the other hand needs to be highly customizable to be able to use every space in the paper. Please correct me if I am wrong(I don't use the feature as a user). - ShareLayout could be the backend for what i describe - a ShareLayout will determine the social network share or printout layout - having or not having the profile or the table could be a toggle option in ShareLayout - ShareLayoutOptions could be the frontend that the user interacts with and it generates a ShareLayout - the current PrintLayout could arrange ShareLayouts e.g. user defined NxM layouts - the facebook share will upload a single ShareLayout Can you clarify this part more please, I don't get how user data will be mapped to the ShareLayout? i would ditch the QTablexx implementations completely and implement a custom QPainter that is HTML template based (and probably quite slow). Tomaz at some point proposed a Qt template library for custom printing, but i don't like the idea of adding even more dependencies to Subsurface. if others approve of that, i would do the same. I am interested in using HTML templates that gives high customization to the prints, while the library Tomaz has proposed seems to be very good too. I think we may need Dirk's opinion about the dependency. this part from the ideas page is important: But the team is open to other ideas that solve the underlying problem: being able to customize the print output to include the information that the user perceives as relevant and giving the user control over major style elements like font sizes and positioning of the various data. i think, before you start writing the proposal users should provide feedback on what level of customization they want from the print layouting. I am going to ask for more user input in subsurface user forum. Davide, Robert - any ideas? lubomir -- p.s. please mind there is a chance that i could be AFK for weeks during the GSoC period. -- regards, Gehad ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Customizable Print Formats GSoC 2015
On 3 March 2015 at 01:10, Gehad Elrobey gehadelro...@gmail.com wrote: Hi, As Subsurface became a mentoring organization in GSoC '15 so I am willing to join this year under Subsurface organization. I am interested in the idea of Adding customizable print formats. I am specially interested in this idea as subsurface lacks good printing capabilities and also this project will be some how related to the HTML codebase I wrote in my project last year. Before I start writing my proposal I would like to know the community's (and Lubomir for sure as the mentor) opinions and expectations about the project? and what do you think is missing mainly in the current printing system? some random thoughts, i would agree that some research and user feedback is needed here, since as a non-user the current printing capabilities seem static but sufficient to me! the facebook share is even less flexible than what we have for printing. perhaps it's possible to unify the backend for social network share layouting and the print layouting, since doing a printout is probably for the purpose of sharing: - ShareLayout could be the backend for what i describe - a ShareLayout will determine the social network share or printout layout - having or not having the profile or the table could be a toggle option in ShareLayout - ShareLayoutOptions could be the frontend that the user interacts with and it generates a ShareLayout - the current PrintLayout could arrange ShareLayouts e.g. user defined NxM layouts - the facebook share will upload a single ShareLayout i would ditch the QTablexx implementations completely and implement a custom QPainter that is HTML template based (and probably quite slow). Tomaz at some point proposed a Qt template library for custom printing, but i don't like the idea of adding even more dependencies to Subsurface. if others approve of that, i would do the same. this part from the ideas page is important: But the team is open to other ideas that solve the underlying problem: being able to customize the print output to include the information that the user perceives as relevant and giving the user control over major style elements like font sizes and positioning of the various data. i think, before you start writing the proposal users should provide feedback on what level of customization they want from the print layouting. Davide, Robert - any ideas? lubomir -- p.s. please mind there is a chance that i could be AFK for weeks during the GSoC period. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
