Moon phase is reversed in dark mode.

[iago-lito]

It feels stupid, but since my terminal writes light letters on a dark background, the moon phase seems just the opposite of what it should 8) For instance, it's full moon today, but:

How could we improve this? I guess the simplest, in order not to have to detect the terminal colors, is to provide a flipmoon option?

[chubin]

It is a good point. Actually, they are not reversed per se, or better to say the dark mode is not the problem, but the problem is the font where the moon phases are inverted; we can add a new view, v2im(v2 + inverted moon) where the moon will be inverted. What do you think?

[iago-lito]

I think it's the best, provided we make it clear for users in the doc and/or the FAQ (I can do this if you need). Also, it does not make it impossible to automatically adjust this option in the future based on detected font/color of the terminal.. although I'm not sure how to do this without using some kind of dark magic X)

BTW, I'm not sure how v2 is organized, but how long will it be until you run out of name variations like v2im etc.?

[egmontkob]

but the problem is the font where the moon phases are inverted

I'd argue that the problem is that Unicode is faulty here.

The description of many of its codepoints include the words "black" and/or "white", matching the reference rendering inside the PDF which has a white background and black foreground. Examples: BLACK SQUARE ■ (U+25A0), WHITE SQUARE □ (U+25A1), BLACK SMILING FACE ☻ (U+263B), WHITE SMILING FACE ☺ (U+263A) etc.

The usage of the words "black" and "white" in the names of these glyphs become invalid as soon as one paints them with different background and/or foreground colors.

Moon phases are defined, and their reference glyphs are shown the folliwing way: new moon is a filled black circle, and full moon is a black circle outline. That is, white stands for lit, black stands for dark inside the circle, but the white part outside the circle doesn't make sense. There is no combination of background and foreground color for which this results in an intuitive depiction of what people see when they look up to the sky.

The opposite definion would make much more sense. At least on "inverted" colors (dark background, white foreground) the result would be exactly what you see on the sky. But even on Unicode's standard white background and black foreground, a completely inverted picture (that is: "black" meaning "shining" over a big white canvas) is in my opinion much easier for the human brain to process than inverting just what is outside the circle, and not inverting what is inside.

Yet another analogous example: Go to a blackboard with a white chalk in your hands and draw a chess board. Most likely you'll chalk-shade the "black" fields (e.g. A1) and leave out the "white" ones, resulting in a fully inverted picture.

Now, some fonts may have perhaps inverted what Unicode did, I'm not sure about that.

Some other fonts (e.g. the one I happen to be using, "Monospace" on Ubuntu) have real colored emoji-like glyphs here, e.g. partially gray (dark side of the Moon) and partially yellow (light side of the Moon). This displays intuitively over both dark and white background.

Conclusion? Well, nothing new to what you already have. Probably you should stick to Unicode's semantics (the name of the codepoints) by default, and add an option to invert it.

---

As for the choice of v2im, I share iago-lito's concerns. As soon as you add another option (e.g. I just filed #371), this scheme becomes unmaintainable. How about just another boolean "view option"?

[chubin]

Maybe, if we add the I option (see also #371) for the v2, we could also use to force inversion of the moon symbols too?

[egmontkob]

If you automatically invert the moon phase as a side effect of any other option that is not explicitly about this, you'll break it for fonts that have emoji-like coloring.

Also, a semantically incorrect output (even if fixes the visuals in some setups) might lead to troubles for people who postprocess the output in any way, e.g. by a script, or copy-paste the symbol to a document, or screen reader etc. I'm not saying it's bad per se to have such an option, but in my firm opinion it should have its dedicated option then.

Another approach you might consider is to print the semantically correct glyph using inverted colors. Which looks ugly due to the inverted square it creates, but this approach might be auto-connected with I.

[egmontkob]

I just realized that the Unicode moon shapes are even more broken.

They, along with their reference glyphs, only consider the northern hemisphere. On the southern hemisphere the moon phases look the opposite (and not in the "inverted" sense that the I option was proposed to do, but in the "mirrored" sense). Near the equator the moon is an upper or lower crescent, depending on the time of day, so even the concept of representing one moon phase with one symbol cannot work.

[iago-lito]

@egmontkob This is a suprising limitation indeed! Do you think it is worth reporting to Unicode?

[egmontkob]

I guess so. I'm not familiar with Unicode's processes, e.g. where to report it. Do you feel like going ahead with it?

[egmontkob]

I'm thinking how they could fix it. They should probably leave the current glyphs defining semantics (I guess they have a rule that they never change the text description of assigned codepoints, so "fixing" the current ones to be about the look rather than about the semantics is not something they'd go for). Some fonts could come up with "southern hemisphere" variations here.

And they should define tons of new ones for the looks (including at least 90° rotated, but maybe even 45° rotated variants of the current ones). They would have some overlap with the currently existing ones, assuming their "northern hemisphere" interpretation; however, these new ones would not be mangled by "southern hemisphere" font variants, so they would actually be different.

[iago-lito]

+ I guess all this makes no sense in any tropical country, where the crescent is very close to zenith so you can view it either side.. or even rotated 90° either way :P

I'm not familiar with Unicode's processes, e.g. where to report it. Do you feel like going ahead with it?

Me neither. But I can have a look at their process after I get through a couple of deadlines :)

What I'm pretty much sure is that their timescale on processing this kind of requests must be very long. And that a couple of options to work around this would still be meaningful at wttr.in :)

[iago-lito]

I've found a workaround by chance.

After I installed noto-fonts-cjk and noto-fonts-extra packages yesterday on my Arch distrib (for other reasons), the problem solved by itself X)

^{_{(BTW what a shitty weather we have this week, can I open another issue for that? X)}}

[chubin]

@iago-lito Perhaps, we should add this advice about the fonts to README

^{_{(and I see that the weather at Montpellier is much better today)}}

[iago-lito]

@egmontkob

I guess so. I'm not familiar with Unicode's processes, e.g. where to report it. Do you feel like going ahead with it?

I've found this today. I think it is an official report, so they seem aware of the problem at Unicode.

I also think that this is the contact form to report anything to them. But I'm not sure we have anything new to add :P

[chubin]

@iago-lito Very interesting document. Maybe we should add a link to it to README.md with some short clarification.