search

TASVideos / tasvideos

The code for the live TASVideos website
https://tasvideos.org/
GNU General Public License v3.0
62 stars 29 forks source link

Wiki pre monospace problem #1229

Closed meshuggahtas closed 3 days ago

meshuggahtas commented 2 years ago

I don't know what is the intended feature, but ascii arts seems wrong when using pre to have monospace (equally proportioned distance and size between all characters).

Here's an ascii art with monospace (single space in front of line) which shows that some characters are way too long vertically and makes the lines fall through the next.

https://tasvideos.org/SandBox?revision=16

edit: the original page I copied from to compare with (note, it's not monospace in the original) https://textart4u.blogspot.com/2012/03/mario-text-art-ascii-art.html 6th Mario on the page

edit2:

nattthebear commented 2 years ago

Could you post a screenshot from somewhere where it looks bad?

MemoryTAS commented 2 years ago

is there anywhere where ascii art is prominently used besides the sandbox?

meshuggahtas commented 2 years ago

TextFormattingRules says: Please use preformatted text for program source code and such only.

Working ASCII art:

Not working ASCII art:

SamsaraTAS commented 2 years ago

It's great that you're involved in helping out the site, but my dude, this is literally "ASCII art is slightly misshapen". Issues on this tracker should be things that could conceivably affect the average user using the site as intended, or things that would actively harm the site in the off chance that someone decides to try something funny. I feel like posting literally every single extreme edge case you come across does nothing but bloat the tracker and make it a lot harder for people to find and fix critical issues.

meshuggahtas commented 2 years ago

I was about to write a new comment to be sure we are on the same track. Monospace is widely used in faq's to show the layout of levels and other route strategies for example Darius level strategies.

It's perfectly fine to disallow ASCII arts (posting text graphics that doesn't contribute to TASing in anyway).

I think supporting Monospace to get correct level layouts should benefit TASers.

If it doesn't, just close this issue and say "we don't want to support ASCII arts. go and open those TXT files yourself".

CasualPokePlayer commented 2 years ago

https://github.com/TASVideos/tasvideos/labels We have labels for a reason, extremely low priority issues get Priority: Bottom. If labels aren't being applied consistently for this purpose then that is another issue entirely.

meshuggahtas commented 2 years ago

As a contributor without committing fixes, I refrain from giving priorities as I don't want to give goals to the developers, but I add it after you mentioned it.

meshuggahtas commented 2 years ago

Issues on this tracker should be things that could conceivably affect the average user using the site as intended, or things that would actively harm the site in the off chance that someone decides to try something funny. I feel like posting literally every single extreme edge case you come across does nothing but bloat the tracker and make it a lot harder for people to find and fix critical issues.

What is the developers/project leaders opinion? What should I do with those bugs?

I already have an external google sheets with ~40 issues that called Future Issues to avoid "bloating" the issue tracker.

As soon as I recognize a bug or a missing feature, I head on this issue tracker and make a new issue and label with what I see apply for it.

I think I don't need to say that I'm trying to help and not make things more difficult. I will abide whatever answer I will get for this question/issue tracker handling stuff.

edit: I suggest developers that when they are looking for fixing stuffs, they should use the labels link what CasualPokePlayer linked. It's much easier to handle tickets with labels rather than going through ~200 issues uncategorized.

CasualPokePlayer commented 2 years ago

A bug is a bug. It should be posted on the issue tracker. It will be closed when it is fixed or if it's unfixable (i.e. not our problem).

If there is a concern about bloat, then labels are not being used enough. Labels filter issues. These should be applied consistently across issues. If they are not, then you get unfilterable bloat.

meshuggahtas commented 2 years ago

I think I made a good job with labeling a lot of issues. I refrain from creating new labels because I didn't wanted to introduce new terms without the developers knowing what I've meant for them (avoiding confusion). I would like to request appropriate labels for issues that doesn't have labels so I can apply it to them.

Note there's only 6 open issues without labels https://github.com/TASVideos/tasvideos/issues?q=is%3Aopen+is%3Aissue+no%3Alabel edit: well, some issues only have "bug" or "enhancement", don't know how to link "only 1 label" filtered issues url.

nattthebear commented 2 years ago

The behaviors on Chrome (Windows) and Firefox (Windows) are fine and expected. Monospace fonts don't in general guarantee precisely identical character heights on all glyphs, only that the horizontal spacing is even.

The behaviors on the mobile devices are pretty bad. Looks like we're using a Bootstrap provided font stack? I'm surprised it would be such a train wreck on such common devices. Do our source code tags have working monospace behavior? If so, we could use that font.

I'd like us to get to the point where monospace is actually monospace, but ascii art as an artform is way too fontface and renderer specific to guarantee any particular compatibility.

Masterjun3 commented 3 days ago

I'm closing this issue. From the site's perspective, we instruct the browser and OS to display the text in a monospace font. That's all we can do. If a font doesn't have data for a certain glyph it will use a fallback font. And this fallback font's glyph might not be the same width.

This is just like someone posting a newly released emoji on the forums that some devices haven't supported yet. If you aren't careful, some people can't see what you're posting. So if you post monospace with frequently used characters, many fonts support that, so many people can see it properly. If you don't, then people don't see it properly. The site can't do anything about this. This isn't a bug on our side.

If anyone has any specific monospace font that is widely supported and that they know can improve some frequent monospace characters better than our current monospace stack, then you can suggest that. But currently it doesn't make sense to have this issue ticket open, because there is no perfect solution, and we already do the best we think we can.