This is about engine colors and misc. Almost through now:)
Am Freitag, 18. Mai 2018, 17:04:09 CEST schrieb Dileep Sankhla:
6. tools.xml has <engine color> and <annotation color> tags. The engine
color is used -
i) to colorize the overlay icon with engine color that is drawn
on tool-base-okular icon for every annotation toolbar icon[1].
ii) to set annotation background color to engine color if <annotation
color> tag is absent[2].
It is clear that we should omit <annotation color> tag and wherever it
is
calling Okular::Annotation::Style::setColor() function, we should pass
QColor(255,255,255,0) //alpha is 0, so transparent
But we need engineColor to colorize our overlay icon. We can't omit it.
I'll add another question to this. If a 3rd party PDF composer (e.g.
LaTex pdfcomment) sets both /IT = /FreeTextTypewriter and /C = [ <some
color> ] but no /AP, how shall this be rendered? It's valid PDF. Okular
can't do much about it, it's solely poppler that decides. Maybe we want
to ignore /C for typewriter and force background to transparent also
inside poppler?
6.1 We want to set overlay icon's color as the current font color being
set
for typewriter only if we implement font color. Else we will have a
black
colored icon. So if the community agrees on implementing the font color
feature, do I need to first demo this with typewriter icon? Or should
we
agree on black font and implement it only when the font color feature
is
done?
Imho it's not bad if we start with an always-black icon. Regarding demo,
I believe that tool GUI is the easier part wrt font color, so a
dedicated GUI demo is not absolutely required, but doesn't hurt either.
API design and core functionality in okular and poppler are the harder
parts regarding font color.
I don't know how to make a demo. Maybe something like
Okular::Annotation::Style::setFontColor() which will save color in
private
data without applying it to the annotation and set a demo by simply
choosing, saving, reading font color and set the same icon color? This
is
how we do for annotation color but here not applying to the annotation
at
all.
For which purpose do you want to demo? Shall it be a tool GUI/config
demo or an annotation API demo?
Annotations (i.e. Okular::Annotation objects) live independent from the
tool that once has created them. If you want to demo the tool, you want
to persist data in tools.xml/okularpartrc, not in docdata. In a demo,
PickPointEngine can simply omit passing a font color to the
Okular::Annotation object it creates.
To extend item AnnotationTools from tools.xml/okularpartrc you have to
extend DOM parsing in every place it happens. From KConfig perspective,
Settings::annotationTools() is just a list of strings. It doesn't know
that those strings actually contain XML data. Therefore KConfig can't
generate setters and getters for the deeper attributes like shortcut,
engine, type. They're only accessed by Okular code like in
PageViewAnnotator::reparseConfig. To add a new attribute you have to
find all places where strings from Settings::annotationTools are parsed,
and parse for your new attribute "fontcolor".
How will the demo be isolated from a functional patch? I'm asking
because we should aim for a patch that can be merged to master. It must
not have non-functional GUI elements. If you do a second patch dedicated
for demo, that's fine. If it's all mangled into one patch, the patch
probably wont land.
6.2 Now engineColor is also responsible for annotation color, which we
want
transparent. I don't know if <annotation color="#00ffffff"> will set it
to
transparent or should we omit this tag?
I'd say we should omit a color attribute in config places where it has
no meaning. For typewriter it has no meaning, because we force it to
transparent anyway.
Basically, annotation color is set as a common attribute to all
annotation
types at the end of the file and if we should bypass it with an if
condition that will set annotation color for type "typewriter"
hardcoded to
QColor(255,255,255,0).
I have tried harcoding it for inline note and in the appearance
settings, I
got a transparent color but as soon as I create a note, it's background
turns to white. and I find color: white in the appearance settings
again.
Will it work for the typewriter then?
No, if it doesn't work for inline note it also won't work for
typewriter. We have seen transparent background working in our Qt5
poppler demo
https://cgit.kde.org/scratch/dileepsankhla/okular-gsoc2018-typewriter.git/tree/src/main.cpp#n24.
So the alpha channel obviously gets lost somewhere inside Okular. Can
you try to hunt the QColor down the stack and see where this happens?
Cheers
Tobias
