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

Add more default Windows-1252 characters #23

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

dwatteau
Copy link
Owner

Using scummfont on later non-English SCUMM games, we can see that some characters (such as some Spanish characters) are often present at the same positions, so if they're reliably put at the same places, we could consider them "canonical" and add them by default, to avoid having to type escape sequences for them.

This doesn't mean that the used fonts will always have them, but it's probably a good idea to settle on "official" character positions, before everyone puts them at different places in their own font modifications.

It's an incompatibility between Windows-1252 and ISO-8859-1, and it looks
like no V1-EN game uses it anyway, to the best of my knowledge.

It's still possible to use the associated escape sequence, if necessary.

Issue #5.
Add the "í", "ó", "ú", "ñ", "Ñ", "¿" and "¡" characters to the
internal Windows-1252 table, since they appear by default in some
SCUMM games at the same positions.
@dwatteau
Copy link
Owner Author

I've added some characters present in Indy4.

The Dig has a bit more characters, too. I need to look into that.

Also, we output Windows-1252/ISO-8859-1, but the internal SCUMM fonts seem to follow CP-437 or CP-850 (which look plausible, since the games have a huge DOS background):

https://en.wikipedia.org/wiki/Code_page_437
https://en.wikipedia.org/wiki/Code_page_850

I need to look at various fonts from various SCUMM games, but if this is confirmed, then we could just provide a CP-850 -> Windows-1252 mapping for all Western European characters when using -c.

…s used

By default, SCUMM games often render the quotation mark symbol (0022)
and the grave accent (0060) with the same glyph, but for some cases or
for some languages, it's probably better to output them as different
characters, as is done is the default ASCII mode (i.e. when -c is not
used).
It appears that most SCUMM games actually follow the MS-DOS CP 850
code page internally, so we can try recognize any "useful" but missing
CP 850 character, as long as they're available at the same codepoints
in both Windows-1252 and ISO-8859-1, and as long as no SCUMM game
already uses that codepoint.

Warning: recognizing it doesn't mean that it will work in-game. It
may not have been drawn in the included font; use scummfont for that,
if necessary. The idea is to settle on a safe subset/variant of the
MS-DOS CP 850 code page.

This should improve compatibility for Western European alphabets such
as the ones used in the French, Italian, Spanish, Irish, Portuguese,
Welsh, Icelandic, or Scandinavian languages. They're also a bit of
improvement for some Eastern European alphabets.

It is still incomplete and biased towards Western European languages.
Sorry for that, but this is the historical behaviour of these games.
Hopefully we'll find another way of improving the situation for other
languages, alphabets and users… in the meantime, it's still possible
to use the ASCII mode, and do your local modifications to the included
fonts, but it's not convenient.
@dwatteau
Copy link
Owner Author

I tried importing some more "safe" characters from CP-850 (the details are in the commits and comments).

This will need some serious testing…

@dwatteau dwatteau self-assigned this Mar 30, 2021
@dwatteau
Copy link
Owner Author

dwatteau commented Apr 1, 2021

I need to check the font from Loom EGA FR again; it looks like it has some local changes compared to CP850…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant