Created attachment 20056 [details] Above is Evince, below is Okular. Please refer to the attached picture.
I can't see any noticeable different, can you please point to them?
Hi, I guess you are not Chinese :-) Anyway. for Latin characters, poppler-qt4 is acceptable. Please refer to the attachment. For us, it is considered an unacceptable rendering quality. Thanks very much if you could help to improve it. We do not expect high, just as good as Evince does. On Wed, Nov 5, 2008 at 4:31 PM, <bugzilla-daemon@freedesktop.org> wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=18379 > > > > > > --- Comment #1 from Albert Astals Cid <tsdgeos@terra.es> 2008-11-05 00:31:24 PST --- > I can't see any noticeable different, can you please point to them? > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug. > You reported the bug. >
I've ALREADY looked at the attachment and can not see anything that makes my european eyes cry, so point me EXACTLY at what problem you see please.
Hi, I am not a postscript expert nor am I an expert in high quality PDF rendering technique. To put it simple, they are different and the difference matters. Anyway, see if it can be *improved*. Take it ease if it can not be. Thanks. On Thu, Nov 6, 2008 at 4:15 AM, <bugzilla-daemon@freedesktop.org> wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=18379 > > > > > > --- Comment #3 from Albert Astals Cid <tsdgeos@terra.es> 2008-11-05 12:15:31 PST --- > I've ALREADY looked at the attachment and can not see anything that makes my > european eyes cry, so point me EXACTLY at what problem you see please. > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug. > You reported the bug. >
It looks like the glyphs in the top window are rendered with freetype’s autofitter (possibly the light version) and those in the lower window are rendered by way of the byte code interpreter. Or perhaps the difference is due to differing (sub-)pixel alignment. In the lower window some—but not all—of the glyphs have their vertical and horizontal stems snapped to whole pixels; none of the glyphs in the upper window are snapped to pixel boundries. It is the difference between having some stems snapped—and therefore black—and others soft grey which makes the okular rendering objectionable. In short, the (typographic) colour of the text should be even, and that version of okular/qt4/freetype/fontconfig/ubintu, as configured, is not generating even colour. I don’t know whether ubuntu ships freetype with or without the BCI. If not then the difference is most likely either that okular or qt4 is aligning the glyphs on pixel boundries—which would allow the autofitter to draw vertical and horizontal stems in black—or that ocular/qt4 is using the default autofitter and evince/cairo the light autofitter. If ubuntu does compile freetype’s BCI, then I’d bet okular/qt4 is using it whereas evince/cairo is not. The font may have some glyphs which lack instructions or for which the instructions just aren’t as good as for other glyphs. And one last possibility is that they are choosing different fonts, if the pdf does not embed. (My first guess was embedded bitmaps, but if you look at the snapped glyphs well magnified it is clear that they are not bitmaps.) Nanmus: just in case the PDF does not embed its fonts, you can see which fonts each of evince and okular are using by examining the file /proc/$PID/fonts (where $PID is the process id as shown in ps or top). I’d do: :; egrep -i '([ot]tf|pf[ab])' /proc/$PID/maps That will show all of the fonts the process loaded by way of fontconfig; both for the document and for the user interface. Compare that with the output of pdffonts on the pdf you are using to see whether differing font choices is relevant. Unless, of course, if you know that the PDF embeds all of the fonts which is uses....
Hi, thanks for the professional reply which is very impressive. I guess now you clearly know what the problem is and please get it fixed. Thanks again. ps: I use Kubuntu instead of Ubuntu. On 11/7/08, bugzilla-daemon@freedesktop.org <bugzilla-daemon@freedesktop.org> wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=18379 > > > > > > --- Comment #5 from James Cloos <cloos@jhcloos.com> 2008-11-06 10:16:57 PST > --- > It looks like the glyphs in the top window are rendered with freetype's > autofitter (possibly the light version) and those in the lower window > are rendered by way of the byte code interpreter. Or perhaps the > difference is due to differing (sub-)pixel alignment. > > In the lower window some—but not all—of the glyphs have their vertical > and horizontal stems snapped to whole pixels; none of the glyphs in the > upper window are snapped to pixel boundries. > > It is the difference between having some stems snapped—and therefore > black—and others soft grey which makes the okular rendering objectionable. > > In short, the (typographic) colour of the text should be even, and that > version of okular/qt4/freetype/fontconfig/ubintu, as configured, is not > generating even colour. > > I don't know whether ubuntu ships freetype with or without the BCI. If > not then the difference is most likely either that okular or qt4 is > aligning the glyphs on pixel boundries—which would allow the autofitter > to draw vertical and horizontal stems in black—or that ocular/qt4 is > using the default autofitter and evince/cairo the light autofitter. > > If ubuntu does compile freetype's BCI, then I'd bet okular/qt4 is using > it whereas evince/cairo is not. The font may have some glyphs which > lack instructions or for which the instructions just aren't as good as > for other glyphs. > > And one last possibility is that they are choosing different fonts, if > the pdf does not embed. > > (My first guess was embedded bitmaps, but if you look at the snapped > glyphs well magnified it is clear that they are not bitmaps.) > > Nanmus: just in case the PDF does not embed its fonts, you can see > which fonts each of evince and okular are using by examining the file > /proc/$PID/fonts (where $PID is the process id as shown in ps or top). > > I'd do: > > :; egrep -i '([ot]tf|pf[ab])' /proc/$PID/maps > > That will show all of the fonts the process loaded by way of fontconfig; > both for the document and for the user interface. Compare that with the > output of pdffonts on the pdf you are using to see whether differing > font choices is relevant. Unless, of course, if you know that the PDF > embeds all of the fonts which is uses.... > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug. > You reported the bug.
It would be very useful to have the document, could you attach it?
Here it comes. FYI: I generated this file on a Mac using xetex in texlive 2008 where the fonts used are STSong, STKaiti,STHeiti bundled by Leopard by default. On Sat, Nov 8, 2008 at 11:56 PM, <bugzilla-daemon@freedesktop.org> wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=18379 > > > > > > --- Comment #7 from Albert Astals Cid <tsdgeos@terra.es> 2008-11-08 07:56:40 PST --- > It would be very useful to have the document, could you attach it? > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug. > You reported the bug. >
I think you probably attached the file to a mail and the interface between mail and bugzilla dropped it, please go to http://bugs.freedesktop.org/show_bug.cgi?id=18379 and click on "Add an attachment"
Hi, the max size permitted is 1mb. The file is 3.2mb On Sun, Nov 9, 2008 at 3:59 AM, <bugzilla-daemon@freedesktop.org> wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=18379 > > > > > > --- Comment #9 from Albert Astals Cid <tsdgeos@terra.es> 2008-11-08 11:59:54 PST --- > I think you probably attached the file to a mail and the interface between mail > and bugzilla dropped it, please go to > http://bugs.freedesktop.org/show_bug.cgi?id=18379 and click on "Add an > attachment" > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug. > You reported the bug. >
Arg, can you please send it by mail to aacid@kde.org ?
Hi, I upload the file at: http://jhcloos.com/poppler/upload.pl and James Cloos will make it available at freedesktop.org. Contact: cloos@jhcloos.com On 11/10/08, bugzilla-daemon@freedesktop.org <bugzilla-daemon@freedesktop.org> wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=18379 > > > > > > --- Comment #11 from Albert Astals Cid <tsdgeos@terra.es> 2008-11-09 > 11:17:39 PST --- > Arg, can you please send it by mail to aacid@kde.org ? > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the QA contact for the bug. > You reported the bug. >
The file up at: http://people.freedesktop.org/~cloos/poppler/sg.zip (and is also accessible directly for those with a fdo account).
Hi, I believe that the patch that I just sent, http://lists.freedesktop.org/archives/poppler/2009-September/005111.html fixes this bug. Please apply this fix to previous releases, at least back to 0.11, ideally to even older releases, as there are a lot of distros who suffer from this bug, at least openSUSE and Ubuntu, and it seems that this is considered a serious bug by many users, see the comments there: http://bjacob.livejournal.com/10641.html Thanks, Benoit
Please apply this fix to previous releases???? What you mean with that? Are you asking distributions to bypass upstream decision (that may be or may be not including this patch)?
(In reply to comment #15) > Please apply this fix to previous releases???? > > What you mean with that? Are you asking distributions to bypass upstream > decision (that may be or may be not including this patch)? > Keep cool :) I'm not talking to distributions here. I'm talking to you, Poppler developers. Otherwise I wouldn't be posting this on the poppler bugzilla. I'm telling you, please consider applying this patch NOT ONLY to the development branch BUT ALSO to the 0.12 branch, the 0.11 branch, etc... Anything wrong with saying that? That warrants you aligning no less that 4 question marks ? ? ? ?
Also, regarding Namus's attached screenshot. I agree that for me too, as a non-Chinese, it is hard to judge which one "looks better". But now that I've fixed the bug, I can tell what's the difference. The top image shows rendering with no hinting at all. You can see that the curves look smooth and natural, but a little bit fuzzy. The bottom image shows rendering with hinting (either auto-hinting or native "bytecode" hinting, that I don't know). Consequently, the curves look crisp, but are a bit distorted to fit the pixel grid, and also the thickness of the curves is often rounded to the nearest multiple of 1 pixel. Even not knowing anything about Chinese writing, it's easy to guess that it destroys the calligraphic properties of the font. Hinting is a trade-off: with hinting, you lose accuracy and naturality of the curves, in order to gain crispness. And apparently, for Namus, that's not a good deal.
Just your construction felt a bit weird, that's why all had all those ? And no, in case i decide to apply your patch i'll only apply it to master and maybe the 0.12 branch, all the other branches are dead. Are you saying namus wants hinting or does not want hinting?
(In reply to comment #18) > Just your construction felt a bit weird, that's why all had all those ? It's OK, sorry if I expressed myself unclearly. And first of all, I should say that I can't presume whether or not you will accept my patch. But even if you don't accept my patch, you now know the exact root cause of this bug so you can fix it in your own way. Thus, one way or the other, a fix will be applied to poppler. Either mine or not mine. So let's rephrase that as saying that please then apply such a fix also to older stable branches. > And no, in case i decide to apply your patch i'll only apply it to master and > maybe the 0.12 branch, all the other branches are dead. First of all, when I said that I believed that the next round of releases (OpenSUSE 11.2, Ubuntu 9.10) would have poppler 0.11. I have just noticed that openSUSE 11.2 has upgraded to poppler 0.12, and that Ubuntu 9.10 also has poppler 0.12. So I can now agree that it is already good to have the fix in poppler 0.12. But I still wonder a bit. Why not be a little flexible? Depending on the importance of bugfixes that appear along the way? This is probably the number one bug that gives people an (unjustified) poor idea of Okular. > > Are you saying namus wants hinting or does not want hinting? I am saying that he wants no hinting. And that is also clear from the sole fact that he claims that Evince's rendering looks nicer. Evince does not use hinting.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/304.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.