Queries regarding adding a new 'typewriter' annotation tool to the toolbar

[Tobias Deiminger]

Hi Dileep,

here's the next one. I just have to correct another typo from my former 
gdb examples. The conditional breakpoints must use double-equal of 
course, like
(gdb) break KConfig::reparseConfiguration if this==0x55555588f310

Now about font color...

Am Freitag, 18. Mai 2018, 17:04:09 CEST schrieb Dileep Sankhla:
> 5. Do I need to implement "font color" for the typewriter annotation
> (didn't propose in my proposal) or we fine with the regular black font?
> This follows the next query.

Your proposal says "[...] annotation toolbar should gain a new entry 
‘FreeText’ that allows to create the FreeText annotation with the 
FreeTextTypeWriter behavior including transparent background, custom 
font style, size and color [...]". Sounds like custom font color is 
proposed. Am I reading it wrong?

However our refined timeline for the first patch ("safe path") doesn't 
include font color. So we're ok with a black font for that first patch.

We can still discuss the priority of font color when it comes to the 2nd 
half of your project. I think font color would be a valuable feature 
(it's also reusable for inline note). A break down of what would be 
required follows.

Currently font color is not much implemented in the Okular/Poppler 
stack. The only place where it is inplemented is 
poppler/poppler/Annot.cc in AnnotFreeText::AnnotFreeText(PDFDoc *docA, 
PDFRectangle *rect, GooString *da) and generateFreeTextAppearance(). 
GooString *da can contain color values with "rg" or "k", and 
generateFreeTextAppearance can generate an appearance stream respecting 
that color values.

Poppler Qt5 frontend API is missing in 
poppler/qt5/src/poppler-annotation.h. There we would need something like
- TextAnnotation::setTextFontColor(const QColor &) or
- TextAnnotation::setTextFont(const QFont &, const QColor &) or
- Annotation::setStyle(Style) with Style::setTextColor(const QColor &)

Okular Core API is missing in okular/core/annotations.h. There we would 
need something that mostly resembles the Poppler Qt5 API, e.g.
- TextAnnotation::setTextFontColor( const QColor & )

XML definition for saved annotaions must be extended to include a place 
for that new font color property. Afaikt there's no explicit XML Schema. 
It's defined by implementaiton. See static void 
AnnotationUtils::storeAnnotation( const Annotation * annotation, 
QDomElement & element, QDomDocument & document ) and static 
AnnotationUtils::Annotation * createAnnotation( const QDomElement & 
element );

A toolbar typewriter tool must remember the configured font color, i.e. 
new attributes in tools.xml and okularpartrc will be required.

Finally UI code, glue code and drawing code is missing in various places 
in between those APIs.

To select an API, I see two questions:

1) Is the new color property something that is meaningful for ALL 
annotaions?
Then it can be in annotation base class. If not, or if it is ambigous 
what it would mean in different specific annotation classes, don't put 
it into base class. Put it eihter directly to the specific annotation 
class(es) where applicable, or define a new pure virtual class that is 
implemented by annotations that support font styling. Iow consider 
Liskov and interface segregation.

2) Which API variants will ensure API/ABI backwards compatibilty?
There will be less arguments about accpeting a patch if it ensures 
API+ABI backwards compatibilty. There's a good reading about ABI 
compatibilty on kde.org 
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B.

Regards
Tobias