bugBattle for Wesnoth - Bugs: bug #21649, Consecutive line breaks not...

 
 
Show feedback again

bug #21649: Consecutive line breaks not rendered as expected with Pango/Cairo (GUI2, etc.)

Submitted by:  Ignacio R. Morelle <shadowmaster>
Submitted on:  Fri Feb 14 05:28:57 2014  
 
Category: BugSeverity: 4 - Important
Priority: 5 - NormalItem Group: User Interface
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: 1.11.xOperating System: Windows, OS X

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri Jul 29 22:00:05 2016, comment #19:

It is worth reminding we have chosen a workaround (which appears to have no unintended consequences right now) but that it is otherwise an upstream issue.

ancestral <ancestral>
Project Member
Fri Jul 29 09:42:02 2016, comment #18:

No, we switched so as to have a better-looking font with thicker glyphs.

Anyway, I'm glad to finally mark this as fixed!

Charles Dang <vultraz>
Project Administrator
Fri Jul 29 09:32:58 2016, comment #17:

Oh right. Is that why we switched font? Well, thanks for the explanation/reminder.

Wedge009 <wedge009>
Project Member
Fri Jul 29 09:29:13 2016, comment #16:

It was resolved by listing only one family_order in data/hardwired.font.cfg:8, as you mentioned below.

Charles Dang <vultraz>
Project Administrator
Fri Jul 29 08:16:06 2016, comment #15:

Release Notes for 1.13.5 has removed this from the list of known issues. Interestingly, I only just noticed this seems to have been resolved as well. I wonder - is it related to the change in font? Or perhaps some change in how text is rendered due to migration to SDL2?

Wedge009 <wedge009>
Project Member
Mon Feb 15 12:00:33 2016, comment #14:

Turns out it's a pretty old bug - or at least bug report. After digging a bit I managed to find https://bugzilla.gnome.org/show_bug.cgi?id=455940

Wedge009 <wedge009>
Project Member
Mon Feb 15 07:58:15 2016, comment #13:

Yes, I saw the win32 connection only after posting previously.

I finally managed to get debug DLLs compiled and see what's going on. I was also able to get correct line breaks in Windows by truncating the font family list to just 'DejaVu Sans'. It's strange that the system falls over with a font family list but I don't really know anything about how pango works. I'll try to put something together for a report.

We could try iterating through the fonts ourselves, but I wonder if it's worth the effort given the symptoms we're seeing is relatively minor. But let's see what happens with the report first.

Wedge009 <wedge009>
Project Member
Thu Feb 11 06:51:02 2016, comment #12:

I'm wondering, though, if the issue is within pango, should we loop trough the list ourselves?

Charles Dang <vultraz>
Project Administrator
Thu Feb 11 06:34:00 2016, comment #11:

I can confirm that fix works on Windows 10. It also has a side effect of reducing character width.

WITH the fix, the result of pango_font_metrics_get_approximate_char_width is 7237

WITHOUT the fix the same result is 10240.

Charles Dang <vultraz>
Project Administrator
Thu Feb 4 06:30:27 2016, comment #10:

The newline symptom does not affect OS X at least as of 1.13.x.

However, what gfgtdf pointed out is certainly the cause of a different bug, #23560.

The font issue goes away if I change line 8 of /data/hardwired/fonts.cfg from a comma-separated string of fonts to just:

family_order=_"DejaVu Sans"

Last I checked, OS X was using 'fc' and not 'coretext', so I don't think that's it.

Could it be an implementation error? The Pango docs seem to suggest that some contexts take comma-separated strings — maybe how we are using them they do not?

ancestral <ancestral>
Project Member
Wed Feb 3 14:01:07 2016, comment #9:

> Thanks. I was looking through the code from pango_layout_line_get_extents() onwards, but I can't seem to work out how the problem exposes itself - not that I was ever good at reading plain C.


The function 'pango_win32_font_map_load_font' does a map lookuo for a string like string 'dejavu sans,japanse,monotype .... ' whihc cannot be found, thus. pango_win32_font_map_load_font, pango_font_map_load_font and pango_context_load_font all return NULL. so pango_layout_get_empty_extents_at_index calculates 0,0 as the size of that line.

> If you know what the issue is, is it worth reporting it to the pango team?


Hmm yes i think it makes sense to report to the pango team.

> Another thought: why is this only an issue on Windows and OSX, but not Linux?


I don't know exactly why this doesn't happen on linux, i thought that the reason why windows behaves differently from linux here is that the windows specific function pango_win32_font_map_load_font is involved (on linux it mostlikeley calls a different function). Don't know about osx though.

Daniel <gfgtdf>
Project Member
Wed Feb 3 12:19:12 2016, comment #8:

Thanks. I was looking through the code from pango_layout_line_get_extents() onwards, but I can't seem to work out how the problem exposes itself - not that I was ever good at reading plain C.

If you know what the issue is, is it worth reporting it to the pango team? Another thought: why is this only an issue on Windows and OSX, but not Linux?

Wedge009 <wedge009>
Project Member
Tue Feb 2 17:20:35 2016, comment #7:

Here is a stacktrace:

Daniel <gfgtdf>
Project Member
Tue Feb 2 13:50:55 2016, comment #6:

That... sounds bizarre. Out of curiosity, which function is that?

Not sure how that relates to the printing of new lines, but that's cool that you found this.

Wedge009 <wedge009>
Project Member
Tue Feb 2 13:39:09 2016, comment #5:

I investigated this issue, and this is related to the fontloading code: the function (inside pango) that calculates the size of empty lines passes a comma seperated list of fonts to a function that can only handle single fonts.

Daniel <gfgtdf>
Project Member
Wed Aug 26 07:19:11 2015, comment #4:

After seeing how the *.po language files are generated, I notice they use '\n' (presumably to render the LF character) to make lines breaks. I wonder, then, for the situations where we are not getting the expected line breaks in Windows, if anything changes if the Windows EOL format of CR-LF (that is, '\r\n') is used.

Wedge009 <wedge009>
Project Member
Wed Aug 12 13:59:49 2015, comment #3:

I notice that the campaign description for Legend of Wesmere is shown with the proper line breaks in the multi-player campaign window, but not the normal single-player one. It looks like they both use the same source directory (data/campaigns/Legend_of_Wesmere/)... I'm guessing the different code used in the two windows accounts for this (is this related to GUI1 vs GUI2?).

Wedge009 <wedge009>
Project Member
Sat Aug 1 13:09:04 2015, comment #2:

Not sure if new Pango/Cairo libraries help. Using Pango 1.37.2 and Cairo 1.14.2 on Windows results in the same single-only new-line issue.

Wedge009 <wedge009>
Project Member
Sat Oct 11 23:52:04 2014, comment #1:

Confirmed by mattsc that this also affects 1.11.x on OS X. He also says that 1.13.0-dev isn't affected, presumably because he's building it with newer Pango and Cairo versions.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Fri Feb 14 05:28:57 2014, original submission:

On Windows (but not Linux), consecutive line breaks are not rendered as expected with Pango/Cairo (via the ttext type) as used by GUI2 or story screens, making it non-trivial to ensure paragraphs of text in the same string have a minimum separation between them.

I'm attaching screenshots of one of the story screens for the first scenario of the A Tale of Two Brothers campaign as one of the most evident examples, but this problem can also be observed with all the mainline campaign descriptions featured in the Campaigns menu, where the line stating the campaign difficulty and length is separated from the rest of the description by two consecutive line breaks to form two distinct paragraphs.

Interestingly enough, there is a (unfortunately very inconvenient) way to work around this issue by inserting a single whitespace character (ASCII 0x20) for each line that would otherwise be empty, i.e. between the line breaks.

I consider this bug to be rather important since it severely impacts the ability of UMC authors to format prose in more text-heavy add-on campaigns in a form that is rendered consistently across all supported platforms.

I have only experienced this bug on Windows myself (outdated Cairo/Pango versions? see also: my note about versions on bug #21648).

Ignacio R. Morelle <shadowmaster>
Project Administrator

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by vultraz (Posted a comment)
  • -unavailable- added by ancestral (Posted a comment)
  • -unavailable- added by gfgtdf (Posted a comment)
  • -unavailable- added by wedge009 (Posted a comment)
  • -unavailable- added by shadowmaster (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Error: not logged in

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri Jul 29 17:23:36 2016vultrazOpen/ClosedOpen=>Closed
    Fri Jul 29 09:42:02 2016vultrazStatusUpstream Problem=>Fixed
    Tue Feb 2 13:39:09 2016gfgtdfStatusNone=>Upstream Problem
    Sat Oct 11 23:52:03 2014shadowmasterOperating SystemWindows XP - 8=>Windows, OS X
    Fri Feb 14 05:28:57 2014shadowmasterAttached File-=>Added wesnoth-win32-double-line-breaks.png, #20045
      Attached File-=>Added wesnoth-win32-double-line-breaks-linux-comparison.png, #20046
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup