Since the bug is in the line collection object, it would make sense to test the _get_dash_pattern() method to make sure it works as expected. The pdf test is useful as an integration test, but the test doesn't explain what exactly it is testing for and why only those parameter values. Do we know that only pdf is affected? What about eps?
…
On Wed, Apr 29, 2026 at 3:23 PM David Stansby @.> wrote: @.* approved this pull request. — Reply to this email directly, view it on GitHub <#31587 (review)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACHF6ACUZCZVEOCFCW542T4YJJDZAVCNFSM6AAAAACYK4IKFKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DEMBQGA2TSMBVGE . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.Message ID: @.***>

I can add a unit test for the _get_dash_pattern() for the new cases but it feels redundant given that the existing pdf case wouldn't pass either if _get_dash_pattern() was incorrect.

I verified that the SVG, PS/EPS, and AGG backends don't crash (and had them in the unit test at first; happy to add them back if you feel like it's needed). They skip setting the linewidth on the graphics context because the empty linestyle list causes Nlinewidths=0 in _iter_collection. Meanwhile, PDF hard crashes because it ultimately ends up calling np.max(linewidths).

Let me know your thoughts @WeatherGod