> And the code goes on to declare some variables, although I don't think
> they are used (there is a check for USE_XFT==1 and I don't see it set
> anywhere).
Well, compiling with USE_XFT=0 gives me indeed the fonts as they looked
before, so I start to believe that the setup of Maven is really using
XFT and it that breaks NEdit as there probably is no
fs->max_bounds.width. I see one easy solution and one proper solution.
easy: compile NEdit with XFT=0
proper: make NEdit more robust against the situation.
I just found out that there is a new upstream release (with a weird
version number with respect to the past) that has multiple changes in
the domain of fonts.
I tend to think that it might be a good idea to get that new version
packaged and included in Ubuntu.
I will work on it and build the package in my PPA. Maven, if I do that,
could you then test the package?
> And the code goes on to declare some variables, although I don't think
> they are used (there is a check for USE_XFT==1 and I don't see it set
> anywhere).
Well, compiling with USE_XFT=0 gives me indeed the fonts as they looked bounds. width. I see one easy solution and one proper solution.
before, so I start to believe that the setup of Maven is really using
XFT and it that breaks NEdit as there probably is no
fs->max_
easy: compile NEdit with XFT=0
proper: make NEdit more robust against the situation.
I just found out that there is a new upstream release (with a weird
version number with respect to the past) that has multiple changes in
the domain of fonts.
I tend to think that it might be a good idea to get that new version
packaged and included in Ubuntu.
I will work on it and build the package in my PPA. Maven, if I do that,
could you then test the package?
Paul