Excerpts from Auguste Pop's message of vie oct 15 18:44:01 +0200 2010: > Thank you for pointing out the reason of rejection, Jose. Well, actually the problem is not that patches are not good enough, the problem is that it's not possible to enable subpixel-hinted rendering without breaking transparencies. For subpixel-hinted rendering to work we would need to first fill the surface in white and then call poppler_page_render to render the page, but PDF blend modes need an initially transparent surface to work. We consider blend modes more important than subpixel-hinted rendering of fonts. > An elegant solution for the subpixel rendering in evince needs > evidently a major change in the underlying data structures, because > the rendering of pdf includes more than simple text on top of white > background. I will try to read the code and understand the application > structure first. > > However, the configuration option I mentioned earlier does not > necessarily mean a graphical preference dialog. I have an empty file > named last-settings in directory ~/.gnome2/evince, thus I assume > having some configurable options around is not totally forbidden in > evince project. > > Best Regards, > > On Fri, Oct 15, 2010 at 11:23 PM, Jose Aliste <jose aliste gmail com> wrote: > > Dear Auguste, > > > > On Fri, Oct 15, 2010 at 10:42 AM, Auguste Pop <auguste gmail com> wrote: > >> Hi, Carlos. > >> > >> I have read the bug report you have pointed out and looked at the > >> patches provided in that thread. If I understand correctly, the > >> situation is like this: evince calls poppler by default option, and > >> poppler calls cairo by default option. Both evince and poppler can > >> force subpixel rendering by setting the appropriate font options. So, > >> the problem can be solved by getting the default options from desktop > >> environment in poppler-glib, or evince, or both. As evince is the > >> application that a desktop user actually use, I still think trying to > >> set the font options according to user's desktop setting in evince is > >> not unacceptable, and adding a configuration option is even better. > > Well, the problem you mention is a bit different and depends on > > solving the bug that Carlos pointed out, which is a difficult bug to > > solve, fwiw. Poppler is a library, so in the end, you should be able > > to tell poppeler whether to use the hinting or not, and evince should > > probably read wether to do so from the font configurations in the > > Gnome Control center and then call poppler with the proper options. > > > > Please bear in mind that Evince does not (and won't) have a Preferences dialog. > > > >> Actually, I think even if poppler-glib sets the font options > >> correctly, setting the options again in evince can still be treated as > >> a safety net. > >> > >> The comment #25 in that bug report seems related to the practicability > >> of subpixel text rendering in poppler. As there is already simple > >> patches that can achieve the expected result, although not perfect, I > >> think the treatment of technical difficulty in corner case areas can > >> be postponed later. > >> > >> This is just my personal opinion, and I would like to see the > >> philosophy behind the delay in fixing this bug for years. > >> > > As you said, this is your opinion. What is happening is that the > > patches weren't considered good enough by the maintainers (and that is > > a decision everyone has to accept, wether we like it or not). The > > philosophy is usally, if the code is not good enough, then don't > > accept it, else the overall quality of the software gets down. Please > > keep in mind that many if not all poppler developers and evince > > developers are volunteers that work on these projects on their free > > time. Unfortunately, nobody can tell you when this bug will be solved, > > and the best thing you can do if you want to solve this bug or any > > other bug is to work on it yourself, that's the freedom in opensource. > > I guess the main message here is that, if you care, please join us to > > make evince and poppler better. > > > > > > Greetings, > > > > José > > > > > > > > > > > >> Best regards, > >> > >> On Fri, Oct 15, 2010 at 4:07 PM, Carlos Garcia Campos > >> <carlosgc gnome org> wrote: > >>> Excerpts from Auguste Pop's message of vie oct 15 08:55:07 +0200 2010: > >>>> Hi, > >>> > >>> Hi, > >>> > >>>> I am not a native speaker, please endure my poor English. > >>> > >>> no problem. > >>> > >>>> I have been using evince for a while and i noticed that evince does > >>>> not respect my system settings of font rendering when displaying pdf > >>>> files. > >>>> > >>>> I have searched the web and find several threads and pages talking > >>>> about this issue. Several different patches exist to solve this > >>>> problem. In most cases, the patch hard-code the subpixel settings in > >>>> function pdf_page_render. However, these kind of patches were rejected > >>>> because of the coding style. > >>>> > >>>> My question is since evince is apparently a gnome application, why not > >>>> use the according gconf to initialize the appropriate > >>>> cario_font_options_t and pass it to the surface? > >>>> > >>>> IMHO, poppler is a library and thus it does not necessarily provide > >>>> the user settings of the system. It should be the library user's (in > >>>> this case, evince) responsibility to set the according variables > >>>> sensible. > >>> > >>> It's a known poppler/cairo issue indeed, see this bug: > >>> > >>> https://bugs.freedesktop.org/show_bug.cgi?id=3307 > >>> > >>> specially comment 25 > >>> > >>>> I am not familiar with all the fontconfig, cairo, poppler thing, and I > >>>> am not sure if getting the subpixel rendering is as simple as setting > >>>> the appropriate font options. If it is not the case, please ignore > >>>> this nonsense. > >>>> > >>>> Thank you for you kind attention. > >>> > >>> Regards, > >>> > >> _______________________________________________ > >> evince-list mailing list > >> evince-list gnome org > >> http://mail.gnome.org/mailman/listinfo/evince-list > >> > > -- Carlos Garcia Campos PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
Attachment:
signature.asc
Description: PGP signature