[Okular-devel] Review Request 109021: Font selector for TextDocumentGenerator
Eike Hein
hein at kde.org
Fri Mar 1 00:28:22 UTC 2013
> On Feb. 19, 2013, 9:51 p.m., Albert Astals Cid wrote:
> > conf/dlggeneralbase.ui, line 300
> > <http://git.reviewboard.kde.org/r/109021/diff/1/?file=114383#file114383line300>
> >
> > This is not strictly true, it also applies for epub, fictiobook, mobipocket and any other future backend that uses TextDocumentGenerator.
> >
> > I think it may make more sense if you add it in the "backend specific" configuration pages in addPages() like the spectre backend does.
> >
> > The naming still needs to be good, not sure i can think of one now. Anyone has ideas?
>
> Azat Khuzhin wrote:
> Yes we could write "Defines font for text based documents." or something like this.
>
> As for addPages() in which window it adds options?
>
> Also I'm not sure about this, because the text also can be extracted from PDF and use the same font for rendering. No?
>
> Azat Khuzhin wrote:
> Sorry for the delay, forgot to publish
>
> Albert Astals Cid wrote:
> "Yes we could write "Defines font for text based documents." or something like this."
> The problem here is, would people consider DVI or PDF a "text based document" because that font is not going to apply there? Also in epub fonts can specify the font sometimes too, so not sure how to properly handle this. Maybe we should have one entry per generator that is a TextDocumentGenerator? This way it would solve the issue since you'd clearly see for all the formats it applies, but it'd mean you could configure different default fonts for txt and for a dfferent format. Does that make sense?
>
> "As for addPages() in which window it adds options?"
> To the "Configure backends" dialog
>
> "Also I'm not sure about this, because the text also can be extracted from PDF and use the same font for rendering. No?"
> It *could*, but it isn't nor won't, doesn't make any sense for PDF where the document specifies the font to use
>
> Azat Khuzhin wrote:
> Do you think that people looking at "Configure backends" dialog often?
> I think that Font settings must be at main dialog, but at hover we must show tooltip "For ... formats". no?
>
> I starting to implement this using addPages() but it is a bit tricky:
> - If people must install font for every backend separately it will annoying.
> - If we will change all fonts in all backends to installed one, when one font for one backend is changed by user, than it will be also not good.
> - And also we can add multiple backends configurations:
> // Something like this
> addPage(w, TextDocumentsSettings::self(), i18n( "Txt\nEPub\n...." ), "okular-textdocuments", i18n("Text Based Documents Backend Configuration") );
>
> But when you need to add another settings, for Txt backend for example, than we must split this.
>
> What you think about this?
>
> Azat Khuzhin wrote:
> Any news?
>
> Albert Astals Cid wrote:
> I have no clue if people look at Configure backends or not, but adding more and more backend-specific options to the general options is a no go. Look at the new pdf-only setting we introduced about line thinness, would it make any sense in the general config?
>
> What do you mean with "install font for every backend"?
>
> I'm thinking we could provide a method in TextDocumentGenerator that returns a QWidget with the common settings and then each generator that uses TextDocumentGenerator can call that function and add stuff to the widget if needed or just return it if it has no extra settings to configure. The question about if it makes sense to have defaults fonts for each text based backend still stands though.
I think going for per-backend options might be the most sensible, especially looking toward future extensibility. For example, the epub backend should ideally have many of the options commonly found in ebook readers, which include text formatting options on a per-element basis (headings, paragraphs, block quotes, ..) as well as the ability to ignore the epub's bundled stylesheets partially (to override the font family, paragraph spacing, paragraph indentation, margins and others - many store-bought epubs come with insane defaults).
Users are also likely to want to use a proportional serif font to read prose text / epubs but a monospace font for plain text files, or at least a sans-serif one, so there's a case to make that different file formats have prevalent use cases and it makes sense to divide the font option between file formats.
The alternative would be to somehow tag generators by use case, i.e. group all "ebook formats" together and have settings for them, but it's unclear we can come up with a better classification (where better would be "less edge cases that don't fit", e.g. an epub doesn't _need_ to be a prose text book) than going by file format.
If per-generator options are too messy, then I guess some sort of cascading settings system would be needed where you could set a default font for all generators and then override per-generator, but that invites quite some complexity.
- Eike
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109021/#review27753
-----------------------------------------------------------
On Feb. 23, 2013, 11:56 a.m., Azat Khuzhin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/109021/
> -----------------------------------------------------------
>
> (Updated Feb. 23, 2013, 11:56 a.m.)
>
>
> Review request for Okular, Albert Astals Cid and Eike Hein.
>
>
> Description
> -------
>
> Development history:
> https://github.com/azat/okular/compare/master...font-selector-for-plain-text-formats
>
> Link to thread from mailing list:
> http://comments.gmane.org/gmane.comp.kde.devel.okular/13279
>
>
> Diffs
> -----
>
> conf/dlggeneralbase.ui f2c9efd
> conf/okular_core.kcfg 054b5c1
> core/textdocumentgenerator.h dd75c5c
> core/textdocumentgenerator.cpp f370ded
> core/textdocumentgenerator_p.h 749d6f2
>
> Diff: http://git.reviewboard.kde.org/r/109021/diff/
>
>
> Testing
> -------
>
> Tested manually
>
>
> Thanks,
>
> Azat Khuzhin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20130301/a0b4dc93/attachment.html>
More information about the Okular-devel
mailing list