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

Location list lines after search on travel map are limited to 29 characters #2684

Open
Daneel53 opened this issue Aug 11, 2024 · 2 comments
Open

Comments

@Daneel53
Copy link

After having entered a search clue on the travel map, the resulting list has lines cut at 29 characters.
This is probably an issue only for other languages than English that are more verbose.

DaggerfallUnity_2024-08-11_09-03-34

This comes from the script DaggerfallTravelMapWindow.cs where the listbox is explicitely created with MaxCharacters = 29.

notepad++_2024-08-11_10-51-48

I changed the 29 for 50 with the Unity editor and the list is is now correctly displayed.

Unity_2024-08-10_22-13-49

Please change this value in DFU code.

@petchema
Copy link
Collaborator

I assume this is done for compatibility with SDF fonts off:
Capture d’écran du 2024-08-11 13-21-14
So it will have to depend on current font mode (or better, if this can be implemented, restrict text drawing to scrollable rectangle, which would work for all fonts, specially variable-spaced ones)

@Daneel53
Copy link
Author

Daneel53 commented Aug 11, 2024

I suppose that 29 characters always were enough for the English names, whatever the font is. So, for English, no matter if the line length is pushed to 50, additional chars shall not be used.
With other languages, we just cannot play with SDF font because this font don't have any character with accent, which make it totally not usable as your example above with esoteric characters that replace the é and the â shows clearly. So, in other languages than English, SDF font is not to be taken into account, we cannot use it.

I think that we can just change this value for the moment, it is clearly better than to have end of lines cut whatever the font is. After that, if somebody have the time and willing to implement a more clever solution that will work for any font, it will still be possible.

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

No branches or pull requests

2 participants