After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 312075 - Fonts are incorrectly displayed in the Scintilla widget
Fonts are incorrectly displayed in the Scintilla widget
Status: RESOLVED WONTFIX
Product: pango
Classification: Platform
Component: general
1.9.x
Other Linux
: Normal normal
: ---
Assigned To: pango-maint
pango-maint
: 311846 334367 (view as bug list)
Depends on:
Blocks: 311846
 
 
Reported: 2005-07-30 18:29 UTC by Trevor Davenport
Modified: 2006-04-12 17:44 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
Screenshot of the font display issues (249.91 KB, image/png)
2005-07-30 18:30 UTC, Trevor Davenport
Details

Description Trevor Davenport 2005-07-30 18:29:07 UTC
Version details: 1.9.1
Distribution/Version: Fedora Rawhide 30 July 2005

Anjuta was the app that I noticed the bug in.  When a text file is opened the
fonts are overlapped, displayed in the wrong place, move and change when
selection occurs.  Seems to happen with the more basic editor off there site as
well.  I know it didn't happen a few days ago which i believe was pango 1.9.0
instead of 1.9.1.  

pango-1.9.1-1
cairo-0.6.0-1
gtk2-2.7.4-1
Comment 1 Trevor Davenport 2005-07-30 18:30:49 UTC
Created attachment 49988 [details]
Screenshot of the font display issues
Comment 2 Sammy Umar 2005-08-02 18:35:13 UTC
I can confirm the same behavior with SciTE on Fedora Core 5-devel using exactly the same  
packages as above. If i go back to pango-1.9.0 and leave cairo at 0.6.0 I get really nice 
fonts. 
 
However, firefox 1.0.6 crashes after a few clicks with the above packages too, so I had to 
go back to cairo 0.5.2. Hope there is a solution so we can admire the nice new look. 
Comment 3 Owen Taylor 2005-08-02 19:41:58 UTC
Somebody who uses Scintilla will have to debug this; I'm not going to get
to it and I can't guess what the problem could be.

(Pango-1.9.0 is not compatible with cairo-0.6.0, I can't imagine how
you are using that combination. There is a fix for the firefox crash
in Cairo CVS)
Comment 4 Sammy Umar 2005-08-03 15:43:57 UTC
There is a new patch from anjuta development by Naba that fixes the problem for
me. This was already a problem with 1.8cvs at some point. So, with the above
packages (cairo updated to fix firefox problem) SciTE works great. The patch 
is at:

   http://cvs.gnome.org/viewcvs/anjuta/scintilla/patches/pango-1.8.patch

Thanks
Comment 5 Owen Taylor 2005-08-04 12:29:09 UTC
Naba - can you comment? I can't make much sense of the patch in isolation.

Is there a Pango bug involved here?
Comment 6 Naba Kumar 2005-08-04 14:14:47 UTC
I am not sure about the pango versions concerned (1.8 in the patch filename may
not be accurate). Somewhere, down the line, there was a change in the behaviour
of pango_layout_iter_next_cluster() (this might be true for other iterations,
but I haven't tested them). It now goes up to one less than it used to before.

For example, in a text of 5 clusters, earlier pango would allow 5 sucessful 
pango_layout_iter_next_cluster() calls until it returns FALSE (in the following
call). Now it goes only upto 4 successful calls. To illustrate the point more
clearly,

Before:
   ___|___|___|___|___|

After:
   ___|___|___|___|___


Where '|' represents the byte index of the iter after the call to
pango_layout_iter_next_cluster() that returns TRUE. The last one returning FALSE
is not shown since the iter is no longer valid and the loop breaks.

This clearly breaks backward compatibility in programs that use the returned
value for iterations -- one loop is left unprocessed.

Hope that helps.
Comment 7 Ray Lee 2005-08-06 21:36:58 UTC
Naba, does that mean if there were text with exactly one cluster,
pango_layout_iter_next_cluster would immediately return false? And if so, then
Owen, was that your intent? I could argue that the API change makes sense and
that users need to adjust their code, but I'm not the author :-).

The pango changeset in question appears to be 1.129.4.5, if that helps jog
anyone's memories.
Comment 8 Naba Kumar 2005-08-08 06:05:24 UTC
Yes, it would. I also agree that the change is more consistent with behaviour of
iteration, where iter always point to the begining of a valid cluster. So if
there are N clusters, pango_layout_get_iter() points at index of first cluster
and subsequent pango_layout_iter_next_cluster() points it to following (N-1)
clusters.

However, the fact that it was done incorrectly before and 'fixed' now has some
serious implication. First is that applications affected by this would have to
take care of both situations if they want to remain compatible with older pango
versions. Second is that it will force the applications to produce immature
releases out -- as if it is some kind of serious security flaw. Third is that
older versions of the application will be simply unusable with the newer pango,
forcing *all* users to upgrade the applications to cutting edge releases.

All the above affects Anjuta and on top of that we have another Anjuta specific
issue. We have stopped developing the stable Anjuta 1.x series and therefore
there likely will be no further release from that series (unless we are forced
to for this specific workaround). Anjuta 2.x is what we are working on now, but
it's not ready for general consumption. If this pango version goes out in the
wild, we have a serious 'blackout' situation -- no usable Anjuta version available.

So whether this 'right thing' actually justifies the pains we will face is
debatable. Also if this bug only affects specific application (e.g. Anjuta) is
not clear. Most native pango applications would use byte iteration or 'length
based iteration' for rendering, while scintilla (anjuta) uses cluster iteration
because of general architectural constrain. But that does not mean anything on
technical ground.

Another issue I noticed is that some people reported the problem when they
upgraded cairo (not pango), or both. So it is possible that this change occured
when pango interfaced with newer cairo (whatever that means, I don't know). I
also noticed that the last cluster in 'Before' scenario acutually has width = 0.
May be there was an 'invicible' cluster there which vanished when interfaceing
cairo in newer cairo.

One solution is to hold this change until there is a major API change in pango
(that is, give some deprecated time to us). I hope this situation is resolved
before pango cvs goes out in public.

Thanks.
Comment 9 Naba Kumar 2005-08-08 08:25:48 UTC
I think the comint on 2005-06-21 by Owen is the one that's causing this. It is
also not related to cairo as I thought before. There have also been couple of
pango releases since, so it's not strictly a cvs only thing now ... hmm.
Comment 10 Naba Kumar 2005-08-09 06:01:28 UTC
*** Bug 311846 has been marked as a duplicate of this bug. ***
Comment 11 Naba Kumar 2005-08-09 06:04:47 UTC
Owen, so what's your resolution on this? We have a terrible situation in Anjuta
and I need to decide quickly.
Comment 12 Behdad Esfahbod 2005-08-09 16:30:59 UTC
Naba, what about you guys put a guard that decides based on Pango version at
runtime?
Comment 13 Philip Van Hoof 2005-08-11 07:32:42 UTC
Comment #12: It's an ugly but perhaps possible solution. However, imho, it
should be Pango that does this type of dirty tricks, not the applications. Since
it's Pango that should aim to provide backwards compatibility. 

Perhaps a "if Pango is initialized by a new-style application, it will behave
like the new way. And if it's initialized by an old-style application, it will
behave like the old way" like solution.
Comment 14 Behdad Esfahbod 2005-08-11 07:40:56 UTC
It's not about backwards compatibility IMO.  It's been a bug in Pango and is
fixed now.  Being compatible to old bugs is, well, counter-productive. :)

About Pango doing tricks, it doesn't really work, since several libraries and
the application may link to Pango at the same time and have different assumption
about the behavior.  Pango cannot satisfy them all at the same time.

If it's only Scintilla, lets roll on and continue.
Comment 15 Owen Taylor 2005-08-15 20:14:17 UTC
Naba - 

I agree that the change was not compatible; but in the end, I'm not 
willing to reintroduce the mysterious "off the end position" that your code
expects. PangoLayoutIter is an iterator over characters and clusters, and
not over positions between characters or clusters. 

PangoLayoutIter was very poorly defined with no test cases. Since it's 
behavior was inconsistent in many ways, it was pretty much certain that
fixing it would cause some sort of incompatibility with existing code.

Sorry for the inconvenience.

(BTW, even most of the work on fixing up PangoLayoutIter is
Amit Aronovitch's, I think I'm responsible for this problem.
To quote bug 89541:

  The need for "extra_eol" in the test case actually was a real problem;
  next_char() and next_cluster() should always go to the next char
  resp. next cluster when there are more chars/clusters, and
  should not include the fake end-of-line runs. Fixing this up
  was quite a bit of work, and I probably broke something...
)
Comment 16 Gianni Moschini 2005-08-26 20:20:57 UTC
Same append here with the following:

pango-1.10.0
gtk+2.0-2.6.7
libcairo2-1.0.0
libqscintilla5-1.5

And I tried with both versions of anjuta (1.2.x and 2.x).

I read your comments, and I don't see any solution here.

I'm reporting the packages versions here to have a clear status on:
In a final result we should resume at what package should be downgraded.. may be
more information have been posted elsewhere.
Comment 17 Owen Taylor 2005-08-26 20:38:02 UTC
The final resolution is that Scintilla must modified.
Comment 18 Sammy Umar 2005-08-26 20:48:04 UTC
You need to apply the patch from Comment #4 to scintilla
Comment 19 Naba Kumar 2005-08-27 05:09:34 UTC
Both scintilla and Anjuta were fixed and released recently.
Comment 20 Gianni Moschini 2005-09-01 23:21:40 UTC
Well, I did install the 1.2.4 today. It compiled nicely.. and now you are right
all have been fixed!

Good work !

Also thanks you for the replies
Comment 21 Johannes Schmid 2006-04-12 17:44:13 UTC
*** Bug 334367 has been marked as a duplicate of this bug. ***