Update Dracula theme from upstream

[akx]

Description

Fixes #487.

Theme Submission Update Checklist

• Included theme in iTerm2 format
• Included 600x300 screenshot, 13pt Monaco font, no transparency
• Updated README.md with new theme and screenshot
• Updated CREDITS.md with new theme
• Ran tools/gen.py to generate themes in all formats
• Updated screenshots/README.md with new theme

[mbadolato]

Great, thank you!

[Gelmo]

@mbadolato @akx There must have been another inconsistency. All of the updated themes that use hex instead of ansi were adjusted to use the wrong color. For example, Ghostty has:

background = #1e1f29
foreground = #e6e6e6

However, the correct values are:

background = #282a36
foreground = #f8f8f2

Based on Dracula's official documentation - https://draculatheme.com/contribute

In other words, foreground was correct but was changed anyway, and background was incorrect and has not been fixed.

[Gelmo]

If these were all generated from the iterm2 theme, it seems possible that the official dracula theme for iterm2 does not respect dracula colors... Don't have iterm2 to test with

[akx]

@Gelmo This is what the Dracula I used here looks like in iTerm2.

[Gelmo]

@akx The background color in that screenshot is incorrect. That uses #24252F, while the official Dracula theme color palette specifies #282A36

https://draculatheme.com/contribute

Actually, it looks like several of those colors are incorrect. There must have been a miscalculation when converting from hex to ansi. I think all Dracula themes in this project should be reviewed to ensure they respect the official color palette.

[Gelmo]

I've just taken a look, and the colors at https://github.com/dracula/iterm do not respect Dracula's real colors lol

[akx]

I've just taken a look, and the colors at https://github.com/dracula/iterm do not respect Dracula's real colors lol

The issue is that those colors don't have a specified colorspace (#349, #354), so they're interpreted as device colors by your iTerm, and when you take a screenshot, that'll be in yet another colorspace.

IOW, it's a bit fiddly to get the same sRGB hexes as specified in color documentation (such as Dracula's) if they've already been transformed to iTerm schemes.

If @mbadolato doesn't oppose it, I'd love to write a PR to make it possible to source schemes from hex colors (and thus convert those themes to well-color-spaced iTerm schemes), and then define Darcula in terms of the official color definition.

[akx]

@Gelmo Do these look more correct?

[Gelmo]

The issue is that those colors don't have a specified colorspace (#349, #354), so they're interpreted as device colors by your iTerm, and when you take a screenshot, that'll be in yet another colorspace.

IOW, it's a bit fiddly to get the same sRGB hexes as specified in color documentation (such as Dracula's) if they've already been transformed to iTerm schemes.

That is very interesting; great catch!

If @mbadolato doesn't oppose it, I'd love to write a PR to make it possible to source schemes from hex colors (and thus convert those themes to well-color-spaced iTerm schemes), and then define Darcula in terms of the official color definition.

Great idea.

• YAML file for each theme
• Generate all schemes from defined colors, even if the upstream theme only provides official schemes and no documentation
• (Mandatory) Define the color encoding used for the values that follow
• (Mandatory) Define the values in the format officially provided by theme docs, if it exists, or from the upstream scheme if not.
  • Contributor guidelines will need to be updated to inform submitters of new themes about the need to refer to upstream documentation rather than upstream schemes, if such documentation exists. (For example, in the case of Dracula, since the official documentation exists, do not use the official Dracula scheme)
• (Optional) Define a list of official upstream scheme files that should be used as-is instead of generating and overwriting
  • This way, if an upstream scheme has a difference from its official theme documentation, and there's a real reason for that to be used instead of what would be generated by the script, that can remain unchanged while allowing schemes for other applications to still be generated from the defined values.

@Gelmo Do these look more correct?

I'll post a response to this in your new PR. I had originally used the screenshot you posted here instead of the the image in the new PR, and there were several issues in the screenshot here which are not present in the new image:

• Background is #282A35 instead of #282A36 (btw, in the official screenshot at https://draculatheme.com/iterm it's also incorrect, at #282A37)
• Foreground/White is #F8F8F3 instead of #F8F8F2
• Can't see what Selection is in the screenshot, so I can't confirm
• Comment/BrightBlack is #6572A0 instead of #6272A4
• Red is #EC625C instead of #FF5555
• Can't see Orange in the screenshot, so I can't confirm
• Yellow is #F3FA9A instead of #F1FA8C
• Green is #85F789 instead of #50FA7B
• Purple/Blue is #B695F3 instead of #BD93F9
• Cyan is #A1E7FA instead of #8BE9FD
• Pink/Magenta is #EE81C3 instead of #FF79C6
• Black is #21222B instead of #21222C
• BrightRed is #ED7773 instead of #FF6E6E
• BrightGreen is #93FC9F instead of #69FF94
• BrightYellow is #FFFFB0 instead of #FFFFA5
• BrightBlue is #CFAEFA instead of #D6ACFF
• BrightMagenta is #F097DB instead of #FF92DF
• BrightCyan is #B9FDFE instead of #A4FFFF

[mbadolato]

@akx I'd be all for it! Anything that makes things simpler, and more correct!

To clarify, are you talking about changing things so a definition file is used for themes, then all (including iterm's) are built from those? It would make life simpler, and allow non iTerm users to submit themes that way.

[akx]

@mbadolato Great! 😁 #512 (still a draft, see within) implements this in a non-intrusive way: both iTerm schemes and YAML-based schemes are source material, and where defined, a YAML-based scheme is considered the source material from which an iTerm scheme is generated. :)