FreeText typewriter annotation WYSIWYG implementation ideas

[Oliver Sander]

Hi Tobias, hi Dileep,

thanks for all the work you are putting into this.

I cannot comment on the technical details of your proposals, but I have some
ideas regarding the more organizational side of things:

* I'd prefer if work was split up such that as much code as possible
will be merged by the end of GSoC.  That means: take smaller subproblems
and really fix and merge them rather than striving for the grand complete
solution which will be left in a branch in an unfinished state by the
end of the project.  Several such subproblems come to mind: actually
finishing and merging the current non-WYSIWIG typewriter, fixing font-related
bugs in poppler, clean-up refactoring steps in pageview and pagepainter...

* The end goal should be a WYSIWYG typewriter tool where poppler does
all the rendering.  Why settle for anything less?  At the same time
I acknowledge that this needs a lot of work to implement, therefore
Idea 2 seems a good current goal to me.

Best regards,
Oliver


On 18.07.2018 09:28, Tobias Deiminger wrote:
> Hi all,
> 
> Dileep and me are still hoping for some community participation for how to rework the GUI of inline note and typewriter. It'll need enduring maintenance and support, so our approach should be backed and agreed by community.
> 
> Please tell us your opinion, be it technical advise or social comments. It can even be a "who cares, stop wasting your time".
> 
> The need for a GUI change is indicated by several bugs:
> - "Improved/consistent mechanism to add/modify inline note" [3]
> - "Reviewtool: Inconsistent input method (for the creation and modification of inline notes)" [4]
> - "Size of inline notes not adjusted to font size and does not respect drawn boundaries" [5]
> - "Inline notes box expands to unspecified size" [6]
> 
> Dileep will start working on this in about 2 weeks as part of his GSoC project. Take a look at his blog, esp. the standalone demo [2].
> 
> I try to sum up our ideas again.
> 
> Common to idea 1 and 2:
> - relinquish the QInputDialog for initial text input
> - don't open popup class AnnotWindow : public QFrame for later text edit
> - but handle both initial and later input in a custom widget that sticks and scrolls to the document, and edits text in WYSIWYG style (similar to how it's already done for PDF form fields)
> - factor out drawing code from PagePainter::paintCroppedPageOnPainter, put it into the new custom widget*
> - factor out UI control code from class PageView, but handle it FormWidget-like and finally delegate events to the new custom widget*
> - after text edit is done, hide custom widget; paint annotation along with the page by generator
> - if generator doesn't support annotations, paint widget by a fallback method in the custom widget in Okular
> * for the sake of SOLID principles
> 
> Exclusive to idea 1:
> - render custom widget by generator even during text input state (override QWidget::paintEvent)
> - introduce layer of abstraction in generator interface
> - pro: No visual inconsistencies (see [7])
> - con: Lots of work, needs additional support in poppler ("multi pass rendering", "render single annotation").
>        The only format that benefits is PDF; no other format has a generator that can render annotations.
> 
> Exclusive to idea 2:
> -during text input state, paint custom widget always by okular (maybe just use plain KTextEdit)
> -if edit state is left, switch render annotation along with the page by generator, if generator supports annotations
> -if generator doesn't support annotaitons, paint widget by a fallack method in the custom widget in okular
> -pro: much simpler because no generator side patches are required
> -con: notable visual difference on switch to generator rendering (currently only in case of PDF, see [2], [8], [9])
> 
> Exclusive to idea 3:
> - don't do the "factor out" parts
> - besides that, just like idea 1 or 2
> 
> [2] https://dileepsankhla.com/wp-content/uploads/2018/05/out.gif
> [3] https://bugs.kde.org/show_bug.cgi?id=358061
> [4] https://bugs.kde.org/show_bug.cgi?id=280622
> [5] https://bugs.kde.org/show_bug.cgi?id=325119
> [6] https://bugs.kde.org/show_bug.cgi?id=353677
> [7] https://bugs.kde.org/show_bug.cgi?id=353401#c25
> [8] https://bugs.kde.org/attachment.cgi?id=111769
> [9] https://bugs.kde.org/attachment.cgi?id=111770
> 
> Am 11.05.2018 18:41 schrieb Dileep Sankhla:
>> Hello all,
>>
>> I'm working with my mentor Tobias Deiminger<haxtibal at posteo.de> on the
>> GSoC project[0] regarding implementing the FreeText annotation with
>> FreeTextTypewriter (WYSIWYG live editing) behavior.
>>
>> I have written a blog post[1] where I have presented three of the
>> ideas to implement WYSIWYG editing in typewriter annotation thus
>> writing directly on PDF page.
>>
>> I would like to invite the okular developers to go through the blog
>> post and help me in choosing the most appropriate approach in order to
>> make this project successful. Your suggestions and comments will be
>> very valuable for me.
>>
>> Thanks and Regards
>> Dileep
>>
>> [0] https://summerofcode.withgoogle.com/projects/#6053164340477952 [1]
>>
>> [1]
>> https://dileepsankhla.com/blog/freetext-typewriter-annotation-wysiwyg-implementation-ideas/
>> [2]
>>
>>
>> Links:
>> ------
>> [1] https://summerofcode.withgoogle.com/projects/#6053164340477952
>> [2]
>> https://dileepsankhla.com/blog/freetext-typewriter-annotation-wysiwyg-implementation-ideas/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5158 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20180718/cfc1876e/attachment.bin>