Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for various font issues #118

Merged
merged 4 commits into from
Aug 23, 2023
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
17 changes: 11 additions & 6 deletions pyfiglet/__init__.py
Original file line number Diff line number Diff line change
Expand Up @@ -260,8 +260,12 @@ def loadFont(self):
Parse loaded font data for the rendering engine to consume
"""
try:
# Remove any unicode line splitting characters other
# than CRLF - to match figlet line parsing
data = re.sub(r"[\u0085\u2028\u2029]", " ", self.data)

# Parse first line of file, the header
data = self.data.splitlines()
data = data.splitlines()

header = data.pop(0)
if self.reMagicNumber.search(header) is None:
Expand Down Expand Up @@ -336,10 +340,11 @@ def __char(data):
# Load German Umlaute - the follow directly after standard character 127
if data:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe drop this if then?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. That was an attempt to fix gradient, which is actually a broken file... Some definitions are missing lines and so pyfiglet runs out of data on the last character. I originally thought it was missing the enter definition, but it dies part-way through in __char().

The real question should probably be whether pyfiglet should soldier on, or reject the font entirely.

Copy link
Collaborator

@stefanor stefanor Aug 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My assumption, when I added that, was that fonts would either have all these german umlaut extensions or not. Just a wild guess, I don't know how the fonts are usually structured.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - that's what figlet does too, but it's clearly happy to stop processing mid character and just use what it found.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the conclusion here. Ready to go or is something outstanding here? I don't have a strong opinion, though possibly it's better to follow figlet's behaviour?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll keep it simple and just remove the erroneous check.

for i in 'ÄÖÜäöüß':
width, letter = __char(data)
if ''.join(letter) != '':
self.chars[ord(i)] = letter
self.width[ord(i)] = width
if data:
width, letter = __char(data)
if ''.join(letter) != '':
self.chars[ord(i)] = letter
self.width[ord(i)] = width

# Load ASCII extended character set
while data:
Expand Down Expand Up @@ -808,7 +813,7 @@ def smushChars(self, left='', right=''):

if self.font.smushMode & self.SM_HIERARCHY:
smushes += (
('|', r'|/\[]{}()<>'),
('|', r'/\[]{}()<>'),
(r'\/', '[]{}()<>'),
('[]', '{}()<>'),
('{}', '()<>'),
Expand Down