Graph Doesn't Render Properly in Chrome

[platramos]

I'm currently trying to create a graphic that visualizes the flow of a conversation between 2 people based on segment lengths. It looks like this when I open it in Preview and Safari:

DESIRED

However, it ends up looking like this when I open the pdf in chrome which is how most people will view it:

CURRENT

I've tried using path.vertical_line_relative():

line_height = 30
for segment in convo_segments:
    utterance_length = (float(segment['end']) - float(segment['start']))
    convo_length = convo_segments[-1]["end"]

    width_of_segment = utterance_length / float(convo_length) * page_width

    if segment['speaker'] == '0':
        with pdf.new_path() as path:
            path.style.stroke_color = '#ff8a5b'
            path.style.stroke_width = width_of_segment
            path.move_to(conversation_cursor, y_axis_starting_point)
            path.vertical_line_relative(-line_height)
            path.close()
    else:
        with pdf.new_path() as path:
            path.style.stroke_color = '#083d77'
            path.style.stroke_width = width_of_segment
            path.move_to(conversation_cursor, y_axis_starting_point)
            path.vertical_line_relative(line_height)
            path.close()

    conversation_cursor += width_of_segment
    total_segments += width_of_segment

and pdf.line()

for segment in convo_segments:
   ...
    if segment['speaker'] == '0':
        pdf.set_draw_color(*salmon)
        pdf.set_line_width(width_of_segment)
        pdf.line(conversation_cursor, y_axis_starting_point, conversation_cursor, y_axis_starting_point - line_height)
    else:
        pdf.set_draw_color(*blue)
        pdf.set_line_width(width_of_segment)
        pdf.line(conversation_cursor, y_axis_starting_point, conversation_cursor, y_axis_starting_point + line_height)
   ...

but they both give me the same output as shown in the screenshot above. Is there something wrong with my implementation or should I be approaching this problem in a different way altogether?

[Lucas-C]

Hi @platramos

Thank you for the bug report.

I'll try to have a look at this asap.

Could you share some example value for convo_segments?
A minimal reproducible example would be ideal.

[platramos]

Thanks for taking a look! Based on what you're seeing do you think there's anything I can try to make it work in chrome? Based on this Chrome is by far the most popular browser so I'd be alienating a lot of my users with this bug

[Lucas-C]

I have crafted a minimal PDF reproducing your issue, independently from fpdf2:

%PDF-1.4
%¿÷¢þ
1 0 obj
<<
  /Type /Catalog
  /Pages 2 0 R
>>
endobj
2 0 obj
<<
  /Type /Pages
  /MediaBox [ 0 0 200 200 ]
  /Kids [ 3 0 R ]
  /Count 1
>>
endobj
3 0 obj
<<
  /Type /Page
  /Parent 2 0 R
  /Resources <<
    /ExtGState <<
      /GS0 << /Type /ExtGState /LW 8 >>
      /GS1 << /Type /ExtGState /LW 7 >>
      /GS2 << /Type /ExtGState /LW 6 >>
    >>
  >>
  /Contents 4 0 R
>>
endobj
4 0 obj
<<
  /Length 105
>>
stream
2 J
1 0.5 0.3 RG
/GS0 gs 10 100 m 10 70  l h B
/GS1 gs 18 100 m 18 130 l h B
/GS2 gs 25 100 m 25 70  l h B
endstream
endobj
xref
0 5
0000000000 65535 f 
0000000015 00000 n 
0000000068 00000 n 
0000000161 00000 n 
0000000396 00000 n 
trailer <<
  /Root 1 0 R
  /Size 5
>>
startxref
555
%%EOF

You can save this to a text file and rename it with a .pdf extension.

It could be used as a base to report this issue to the Chromium dev team: https://bugs.chromium.org/p/chromium/issues/list

It seems related to the use of GraphicsStates (/GS), but what's very strange is that removing the 2 J instruction that sets line cap makes the bug disappear in Chrome!

Based on what you're seeing do you think there's anything I can try to make it work in chrome?

You could try simply using the rect() method

[platramos]

Thanks for looking deeper into this and giving me a base pdf to report to the Chromium team. I just opened a bug with them so let's see what they say 🤞🏽 In the meantime I'll go with rect()

[gmischler]

It seems related to the use of GraphicsStates (/GS), but what's very strange is that removing the 2 J instruction that sets line cap makes the bug disappear in Chrome!

This 2 J should NOT be there!
It should also cause ALL viewers to render this example in the undesired way as illustrated above. Does it not do that?

The operator J sets the line cap style. If set to "projecting square" (2 J), wider lines will also appear longer.
According to the PDF specs (8.4.1, Table 52), the default line cap style is "square butt" (0 J), which is what you really want in this example (and generally, unless explicitly stated otherwise).

I'd say that this line in fpdf.py is a bug and should go away. At the same time, we might want to add a .set_line_cap_style() method (and associated value on the state stack) so that the users can set the desired value explicitly.

[Lucas-C]

Note also that we can already control those settings through the drawing API:
https://github.com/PyFPDF/fpdf2/blob/2.6.1/fpdf/enums.py#L593

I agree that we could get rid of this 2 J setting always present at the beginning of every page content stream.
However this could be a challenge in terms of backward-compatibility, as removing it could trigger visual changes on documents currently generated by fpdf2, that contain this 2 J setting.

[marco-doerig]

You can use rect() which will render correct in any browser. Adapt the following script to your needs (I just changed it quickly to see if it works):

for segment in convo_segments:
    utterance_length = (float(segment['end']) - float(segment['start']))
    convo_length = convo_segments[-1]["end"]

    width_of_segment = utterance_length / float(convo_length) * page_width

    if segment['speaker'] == '0':
        pdf.set_fill_color(255, 138, 91)
        y_axis_start = y_axis_starting_point - line_height
    else:
        pdf.set_fill_color(8, 61, 119)
        y_axis_start = y_axis_starting_point

    pdf.rect(x=conversation_cursor, y=y_axis_start, w=width_of_segment, h=line_height, style="F")

    conversation_cursor += width_of_segment
    total_segments += width_of_segment

I don't know why the other methods don't work.

[platramos]

Thanks for the help @Lucas-C and @marco-doerig I just tried rect() with the code above and it worked like a charm 🙏🏽