search

Pokemon-Standards-Consortium / standards

All standards documents, both final and in progress, are in this repository. Proposals are to be submitted as Issues in here.
10 stars 2 forks source link

Standardized markup for icons in text representation of card data #9

Open Dillonzer opened 3 years ago

Dillonzer commented 3 years ago

Some cards have icons in their name that map to words like Star, E4, etc. We should get some standardization of what these images are in text form.

immewnity commented 3 years ago

I'll second this, and that'll make this PSC 002.

Some observations:

Think that covers all of 'em. Pokémon LV.X don't have the LV.X as part of the card name, so not sure it'd come into play here.

egonolieux commented 3 years ago

Why would LV.X not be part of the card name? https://content.tcgcollector.com/content/images/2e/3c/72/2e3c727b701880f413aa13a9b72b95947e3b22956a2b2c9497eed09ebfb7db79.jpg. I'm not sure how this is different from the other suffixes like V or VMAX.

Regarding Star and Prism star, we could use ☆ and ◇. Those might be special characters, but they are perfectly valid unicode, and should be supported universally.

immewnity commented 3 years ago

Why would LV.X not be part of the card name? https://content.tcgcollector.com/content/images/2e/3c/72/2e3c727b701880f413aa13a9b72b95947e3b22956a2b2c9497eed09ebfb7db79.jpg. I'm not sure how this is different from the other suffixes like V or VMAX.

See page 21 of the rulebook, under "What does and doesn’t count for a Pokémon’s name?":

Some Pokémon cards have extra information after their name, such as a Level or a symbol like [GL]. A Pokémon’s name changes how you can evolve or play certain cards. Level is not part of a Pokémon’s name: • Gengar, Gengar LV. 43, Gengar LV. 44, and Gengar LV.X all have the same name

egonolieux commented 3 years ago

Hmm, I think we are dealing with 2 kinds of names here. I think the rulebook primarily explains how the name should be handled in the context of gameplay. On the other hand, there is the concept of name as the label of the card. It would be confusing to label Pokémon V and Pokémon LV.X differently, simply because they are used differently in-game.

Dillonzer commented 3 years ago

The G, C, GL, and FB cards also, though they can be simplified to G / C / GL / FB

immewnity commented 3 years ago

Hmm, I think we are dealing with 2 kinds of names here. I think the rulebook primarily explains how the name should be handled in the context of gameplay. On the other hand, there is the concept of name as the label of the card. It would be confusing to label Pokémon V and Pokémon LV.X differently, simply because they are used differently in-game.

Keep in mind that Pokémon cards of this era all had levels listed - "LV.X" is simply an extension of this, and not something entirely separate. If LV.X were to be included in the name, IMO all levels should be as well. (fwiw, neither the Card Dex PDFs nor Pokemon.com include LV.X in the card name)

The G, C, GL, and FB cards also, though they can be simplified to G / C / GL / FB

These are all subsets of Pokémon SP - guess I should have enumerated all of 'em.

egonolieux commented 3 years ago

Keep in mind that Pokémon cards of this era all had levels listed - "LV.X" is simply an extension of this, and not something entirely separate. If LV.X were to be included in the name, IMO all levels should be as well. (fwiw, neither the Card Dex PDFs nor Pokemon.com include LV.X in the card name)

True, but LV.X is somewhat of a special case because they have a separate rarity/card type.

MatiasOETamminen commented 3 years ago

On the topic of Lv.X, I think it should be included even if it's not part of the card name in the rules sense, because people refer to these cards as [Pokémon name] Lv.X in speech (unlike the levels).

I agree that we shouldn't use any special characters (non-ascii), not because of technical compatibility but because ease of input.

The character * is a dangerous one, because it could refer either to a Gold Star or a Prism Star. I don't know whether the moniker "Gold Star" is official, but Prism Star certainly is.

Otherwise, I agree with immewnity's initial comment.

nanoNago commented 3 years ago

Yes, there are two kinds of names and both have evident uses for end-users of applications built on top of standardized data.

  1. For the purposes of deck-building, a card's legal name needs to be known and standardized. This often excludes subtitles or other distinctions that are not considered for competitive purposes. Tools oriented around competitions are often likely going to focus on this name.

  2. For everyone else and in all other circumstances, knowing the full, un-truncated title offers value for search specificity and link/slug confidence; by seeing the full title we know that we have identified the correct card. Users interested in aesthetic differences may well search for Giovanni Boss's Orders or Boss's Orders (Giovanni).

This goes a bit beyond the scope of the current issue as I understand it, which is to devise a uniform text markup for denoting the appearance of non-UTF8 symbols as they appear on printed cards. I believe that whether the symbol appears in the "title" or not is actually not strictly relevant.

Should this standard extend to styling markup, or should it remain focused on solely the representation of non-UTF8 glyphs? i.e., do we want to consider only things like the Prism Star icon {*}, or do we want to also consider things like cards with italicized phrases and how to mark that up, too?

(Perhaps the markup is a larger consideration of which the symbols are a component standard thereof, or perhaps we could just roll it all into one to keep it simple for everyone.)

immewnity commented 3 years ago

This goes a bit beyond the scope of the current issue as I understand it, which is to devise a uniform text markup for denoting the appearance of non-UTF8 symbols as they appear on printed cards. I believe that whether the symbol appears in the "title" or not is actually not strictly relevant.

Very good point, I was delving off-topic too.

@Dillonzer , what are your thoughts on scope re: the last part of nago's comment?

Should this standard extend to styling markup, or should it remain focused on solely the representation of non-UTF8 glyphs? i.e., do we want to consider only things like the Prism Star icon {*}, or do we want to also consider things like cards with italicized phrases and how to mark that up, too?

(Perhaps the markup is a larger consideration of which the symbols are a component standard thereof, or perhaps we could just roll it all into one to keep it simple for everyone.)

nanoNago commented 3 years ago

One more concern for the road.

Sometimes the same information is rendered differently on real cards based on where it appears on the card. For instance, "EX" is often rendered in the title area of a card using the {EX} symbol, but when it appears in rule text, it is rendered using plain text instead as "-EX".

We know, as humans, that these two renderings refer to the same semantic concept. A computer, however, needs to know precisely when to render the ideogram and when to render the text. There is therefore a difference between semantic markup and literal markup, where we consider the difference between "Declaring an intent that is, under a certain context, rendered as a symbol" and "Declaring an intent that this unambiguously represents a symbol."

Clear as mud?

What I am suggesting here is that a standardized markup should refer exclusively to the symbol; but we may wish to cross-associate it with other renderings for usability purposes.

For example, a common markup for Prism Star is indeed {*}, but this has a low chance of working well in a text search. For search purposes, we may wish to treat this glyph as equivalent to the phrase Prism Star. For symbols like {EX}, we may wish to define the search text as either "EX" or "-EX". It is possible we want "Pikachu-EX" and "Pikachu EX" to both match a field that is stored (ultimately) as "Pikachu{EX}".

We may also wish to have alternative renderings for screen readers or non-graphical circumstances, e.g. we cannot render the prism star icon in text, so being able to define a non-graphical rendering might be helpful:

Jirachi {*} => Jirachi Prism Star

but that may also be scope creep here. The very simplest possible thing is defining a simple "icon -> markup" table.

nanoNago commented 3 years ago

Some additional data:

pokemon.com uses a few codes on their website; https://www.pokemon.com/us/pokemon-tcg/pokemon-cards/ex-series/ex13/104/ (Pikachu Star) 

<img class="replacedchar" src="https://assets.pokemon.com/static2/_ui/img/sections/tcg/chars/star.png" alt="★">

the replacedchar class shows us a mapping of text to symbols. In this case, ★ becomes the ex-era gold star icon.

Here are all that I have found on the website:

'★': 'https://assets.pokemon.com/static2/_ui/img/sections/tcg/chars/star.png',
'◇': 'https://assets.pokemon.com/static2/_ui/img/sections/tcg/chars/prism_star.png',
'[C]': 'https://assets.pokemon.com/static2/_ui/img/sections/tcg/chars/C_Mark.png',
'[GL]': 'https://assets.pokemon.com/static2/_ui/img/sections/tcg/chars/GL_Mark.png',
'[G]': 'https://assets.pokemon.com/static2/_ui/img/sections/tcg/chars/G_mark.png',
'[FB]': 'https://assets.pokemon.com/static2/_ui/img/sections/tcg/chars/FB_Mark.png',
'[四]': 'https://assets.pokemon.com/static2/_ui/img/sections/tcg/chars/DPt_4mark.png'

AFAICT they do not use images for any of the others, choosing instead plaintext renderings for things like ex, EX, GX, V, VMAX, and so on.

MatiasOETamminen commented 3 years ago

There's also the energy symbols, e.g. Horror Psychic Energy. I would spell the name of the type out.

Dillonzer commented 3 years ago

@Dillonzer , what are your thoughts on scope re: the last part of nago's comment?

I believe we should stick to just the non-UTF8 characters for this issue. The small print / phrases are different in the way we would present card names as a whole I believe. It does sound like a bigger issue for sure.

jparanada commented 3 years ago

There's also the energy symbols, e.g. Horror Psychic Energy. I would spell the name of the type out.

Yeah actually, that's a good call to bring up the Energy symbols! These will show up in effect text quite often, and sometimes in card names as well; a very important decision to be made there. Spelling out Energy symbols is one option here; you'd definitely need to at least bracket them if you go this route. If you don't bracket them you could potentially run into collisions where you don't know anymore if, say, the word "Lightning" was actually spelled out on the original card or was a symbol there (unless you had the card image handy).

The alternative is to use brackets along with the one-letter abbreviations for Energy symbols--G R W L P F D M Y N C, for Grass, Fire, Water, Lightning, Psychic, Fighting, Darkness, Metal, Fairy, Dragon, Colorless. (I think the community has aligned on those letters.)

Either way you then have to decide what kind of brackets you want: square brackets or curly braces (or something else).

egonolieux commented 3 years ago

If we use the bracket notation for the energy types, there will be a conflict with some of the SP card types, [C] and [G] for example. A possible solution would be to use some kind of namespace, like [energy:C], but this would have the disadvantage of being at odd with what most of the community already uses.

To me it seems that these community "standards" use the bracket notation prilmarily for ease of typing and visualization. In other words, they were never designed to be used as markup and rely on the interpretation humans. A human will be able to differentiate a C card type from a Colorless energy most of the time, but a computer won't.

We could come up with our own markup standard using "namespaces", and provide aliases to some of the most well known community notations, such as the bracket notation for energy types (and ignore the C and G card types because they are used less frequently).

That being said, I personally prefer using curly over square brackets, because they seem to be used universally for value substitution in templates.

immewnity commented 3 years ago

Taking a look at the Card-Dex PDFs, square brackets are used for things like SP card types, and curly braces are used for Energy symbols. Maybe that could be a good way to do it, without needing a namespace?

Special Energy is a good question... that might go into the card naming discussion, which probably needs to be split into its own standards document/Issue (or would that be a style decision at that point? IDK). In cases like Horror Psychic Energy, yeah, it's usually spelled out, but things like "Unit Energy Grass Fire Water" are usually shortened. Not sure there's a great way to determine which cards get abbreviated.

MatiasOETamminen commented 3 years ago

For energies/Pokémon types, this is my understanding of the de facto standard abbreviations, whether they're padded in some way or not:

Grass - G Fire - R Water - W Lightning - L Fighting - F Psychic - P Colorless - C Darkness - D Metal - M Dragon - ?? (This is rare, I don't remember seeing it abbreviated, logically should be N) Fairy - Y

nanoNago commented 3 years ago

For energies/Pokémon types, this is my understanding of the de facto standard abbreviations, whether they're padded in some way or not:

They are better than de-facto, they are canon! They have been used in the WOTC oracle text, inside of the card dex app data, and used inside PTCGO metadata.

WOTC used [G] [R] [W] and so on, and so do most sites. PTCGO uses {G} {R} {W} and so on, by recollection. CardDex uses "G" "R" "W" when describing a card type, I do not recall which markup style it uses for in-line type symbols.

egonolieux commented 3 years ago

Taking a look at the Card-Dex PDFs, square brackets are used for things like SP card types, and curly braces are used for Energy symbols. Maybe that could be a good way to do it, without needing a namespace?

I'm personally not a fan of using both square and curly braces. I think that a standard should aim for simplicity and consistency, and using different syntax notations is neither. Also, if we would use different notations to avoid namespaces, there will inevitably be some point in the future where a new abbreviation comes along that will conflict with both notations, forcing us to come up with some 3rd (or 4th and so on) notation, which doesn't scale.

zzo38 commented 1 year ago

I would recommend to use only ASCII characters, for better portability and easier usage. Symbols such as ★, ◇, and 四 probably should not be used, in my opinion.

I think that best would probably be whatever the official documentation for Pokemon card is using, if there is any. For purpose of standardization this would be better, I think.

(I had previously used a different set of symbols in the past, not knowing of this or anything else that tried to represent them in ASCII; my symbols were rather different than anything mentioned here.)