Created attachment 49988 [details]
Screenshot of the font display issues

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. 

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)

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

Naba - can you comment? I can't make much sense of the patch in isolation.

Is there a Pango bug involved here?

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.

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.

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.

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.

*** Bug 311846 has been marked as a duplicate of this bug. ***

Owen, so what's your resolution on this? We have a terrible situation in Anjuta
and I need to decide quickly.

Naba, what about you guys put a guard that decides based on Pango version at
runtime?

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.

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.

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...
)

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.

The final resolution is that Scintilla must modified.

You need to apply the patch from Comment #4 to scintilla

Both scintilla and Anjuta were fixed and released recently.

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

*** Bug 334367 has been marked as a duplicate of this bug. ***