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 14 Feb 2014 05:28:57 AM UTC  
 
Category: BugSeverity: 4 - Important
Priority: 5 - NormalItem Group: User Interface
Status: Upstream ProblemPrivacy: Public
Assigned to: NoneOpen/Closed: Open
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)

Mon 15 Feb 2016 12:00:33 PM UTC, 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>
Mon 15 Feb 2016 07:58:15 AM UTC, 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>
Thu 11 Feb 2016 06:51:02 AM UTC, comment #12:

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

Charles Dang <vultraz>
Project Member
Thu 11 Feb 2016 06:34:00 AM UTC, 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 Member
Thu 04 Feb 2016 06:30:27 AM UTC, 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 03 Feb 2016 02:01:07 PM UTC, 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 03 Feb 2016 12:19:12 PM UTC, 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>
Tue 02 Feb 2016 05:20:35 PM UTC, comment #7:

Here is a stacktrace:

Daniel <gfgtdf>
Project Member
Tue 02 Feb 2016 01:50:55 PM UTC, 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>
Tue 02 Feb 2016 01:39:09 PM UTC, 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 26 Aug 2015 07:19:11 AM UTC, 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>
Wed 12 Aug 2015 01:59:49 PM UTC, 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>
Sat 01 Aug 2015 01:09:04 PM UTC, 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>
Sat 11 Oct 2014 11:52:04 PM UTC, 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 14 Feb 2014 05:28:57 AM UTC, 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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 02 Feb 2016 01:39:09 PM UTCgfgtdfStatusNone=>Upstream Problem
    Sat 11 Oct 2014 11:52:03 PM UTCshadowmasterOperating SystemWindows XP - 8=>Windows, OS X
    Fri 14 Feb 2014 05:28:57 AM UTCshadowmasterAttached 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