Data taken from https://zh.wikipedia.org/wiki/颜色列表
This requires the improved color feature introduced in Pleco 3.2.26 for Android.
This requires the improved color feature introduced in Pleco 3.2.26 for Android.
A dictionary of colors
- Thread starter Peter
- Start date
Cool - somebody should add these to CC-CEDICT 
(since Wikipedia is CC-BY-SA, we can't add it to PLC verbatim, but CC is similarly licensed and so can freely add it)
(since Wikipedia is CC-BY-SA, we can't add it to PLC verbatim, but CC is similarly licensed and so can freely add it)
1. Re-compile this txt file into PQB format so I can import to PLECO as a dictionary? OR:
2. How to add this into CC-CEDICT dictionary manually... if at all possible?
Thanks.
2. Looks like CC-CEDICT has a web interface to accept changes:
https://cc-cedict.org/wiki/todo:todo
https://cc-cedict.org/wiki/todo:todo
Managed to convert this to a PQB file. It does work, but the original version has the character sè (色), which is someone redundant. Imagine having to type black color, white color etc...
I've taken the liberty of amending Peter's file to remove the redundant character. It's Colour(rev).pqb
I've taken the liberty of amending Peter's file to remove the redundant character. It's Colour(rev).pqb
Last edited:
Hi pdwalker,
you can have a look at this summary by alex_hk90:
https://plecoforums.com/threads/multiple-new-lines-in-user-defined-flashcards.5916/#post-44863
Cheers,
Shun
you can have a look at this summary by alex_hk90:
https://plecoforums.com/threads/multiple-new-lines-in-user-defined-flashcards.5916/#post-44863
Cheers,
Shun
Actually in this particular case 4.0 may make things worse - we're currently doing rich text in 4.0 flashcards / user dictionary entries in Markdown, which doesn't have official support for colors at all. If colors are supported they may be only as tone colors through ruby tagging, i.e. you attach a particular pinyin string to a particular span of Chinese characters and then that'll display according to your settings (which might include not actually showing the pinyin at all but only the tone colors), possibly along with a few specific theme colors like grayed-out / highlighted / etc.
Arbitrary color spans are awkward compatibility-wise because they tie our hands as far as background colors / Night Mode / etc go, and arbitrary HTML is currently a nonstarter because we don't think it'll render consistently on everything people use Pleco on (and don't want to be in the position of people expecting us to fix web rendering bugs if for example Xiaomi decides some year they want their own web browser component because the built-in one isn't nearly weird enough to meet the discriminating tastes of their users); we want to support all of the formatting people need to make good useful dictionary entries / flashcards / etc, but only just that much.
Arbitrary color spans are awkward compatibility-wise because they tie our hands as far as background colors / Night Mode / etc go, and arbitrary HTML is currently a nonstarter because we don't think it'll render consistently on everything people use Pleco on (and don't want to be in the position of people expecting us to fix web rendering bugs if for example Xiaomi decides some year they want their own web browser component because the built-in one isn't nearly weird enough to meet the discriminating tastes of their users); we want to support all of the formatting people need to make good useful dictionary entries / flashcards / etc, but only just that much.
Which Markdown dialect are you using? Might I suggest looking at CommonMark if it's not too late?
One of the problems with Markdown, is that it wasn't well specified in the very beginning, resulting in a number of not completely compatible dialects due to ambiguity in implementation. The CommonMark specification nails everything down to avoid this problem.
Also, it supports embedded html, so you could allow html colors within the markdown text (<span color="#RRGGBB">anyone?</span>
One of the problems with Markdown, is that it wasn't well specified in the very beginning, resulting in a number of not completely compatible dialects due to ambiguity in implementation. The CommonMark specification nails everything down to avoid this problem.
Also, it supports embedded html, so you could allow html colors within the markdown text (<span color="#RRGGBB">anyone?</span>
We've built it around a generally CommonMark-compliant library (this one to be specific), but we're modifying that in some ways; we're barring embedded HTML because we don't want to be in the position of having to maintain compatibility with arbitrary embedded HTML and because we want to be able to keep using our own very fast rich text renderer rather than a slow memory-hogging embedded browser control. We actually like + want to stay true to Markdown's foundation as a system for semantic tagging rather than rich text styling; anything that would go in a CSS file should really apply app-wide rather than being overridden by specific dictionary entries.
But we're planning to add some extensions to deal with semantic concepts ('tag' text style, tables, ruby text - some discussion of that here, I generally favor something like [你好]^(ni3hao3) since it's easy to input but hard to stumble on by accident) that are not covered by CommonMark, and we may take a few existing concepts that are irrelevant to us (code blocks e.g.) and repurpose them. ('planning' only because the syntax has yet to be decided - we already do support tables and ruby text in our text layout engine both on iOS and Android, we just haven't settled on how users will key them in)
But we're planning to add some extensions to deal with semantic concepts ('tag' text style, tables, ruby text - some discussion of that here, I generally favor something like [你好]^(ni3hao3) since it's easy to input but hard to stumble on by accident) that are not covered by CommonMark, and we may take a few existing concepts that are irrelevant to us (code blocks e.g.) and repurpose them. ('planning' only because the syntax has yet to be decided - we already do support tables and ruby text in our text layout engine both on iOS and Android, we just haven't settled on how users will key them in)
Well I can safely say it's not coming out in 2018, yes
I can also say that I'd like to have a beta out before summer, because after Apple's WWDC developer conference in June I expect to have a huge new pile of work dumped onto us to deal with iOS 13 (supposedly bringing big UI changes, especially on iPad) and Marzipan (iOS-on-Mac), plus whatever anticipatory half-baked knockoff of those things Google announces at their developer conference in May. But whether or not that will actually happen is TBD.
I can also say that I'd like to have a beta out before summer, because after Apple's WWDC developer conference in June I expect to have a huge new pile of work dumped onto us to deal with iOS 13 (supposedly bringing big UI changes, especially on iPad) and Marzipan (iOS-on-Mac), plus whatever anticipatory half-baked knockoff of those things Google announces at their developer conference in May. But whether or not that will actually happen is TBD.
Ok, done.
Attached are the following files suitable for use with IOS versions of pleco:
- clr-se.xml
- clr-nose.xml
- clr-se.txt
- clr-nose.txt
- Colors-181223.pqb
- PlecoColorConverter.java
The difference between the SE and No SE versions is the removal of the extra 色 character in the definitions. Personally, I prefer having the extra 色 character as it helps with colors like "snow" (需色). Without the 色 to give the previous context, it can be a bit hard to interpret it as a color name as opposed to that fluffy white stuff that falls from the sky.
The attached user dictionary is the + 色 version.
The xml files are based on @Peter 's version, but with the accented characters replaced with tone numbers. Hopefully I didn't make any mistakes during that process.
Lastly, I've not written a real program in well over a decade (except for shell scripts, but that doesn't count), so it didn't matter which language I used to write the converter - except for the fact I couldn't really remember any enough to start writing code, other than C, C#, and java. So java it was. Please note that this code is a great example of voodoo programming. (throw random stuff together until it seems to work)
Last technical note - when the encoded color values came out as a single byte - I had to convert them to a unicode character by flipping the msb so it would encode properly. It seems to have worked.
Thanks to Mike for having the patience to answer my questions on this unsupported feature.
PS: future readers - this is good for pleco v3. It will almost certainly not be correct for v4
Attached are the following files suitable for use with IOS versions of pleco:
- clr-se.xml
- clr-nose.xml
- clr-se.txt
- clr-nose.txt
- Colors-181223.pqb
- PlecoColorConverter.java
The difference between the SE and No SE versions is the removal of the extra 色 character in the definitions. Personally, I prefer having the extra 色 character as it helps with colors like "snow" (需色). Without the 色 to give the previous context, it can be a bit hard to interpret it as a color name as opposed to that fluffy white stuff that falls from the sky.
The attached user dictionary is the + 色 version.
The xml files are based on @Peter 's version, but with the accented characters replaced with tone numbers. Hopefully I didn't make any mistakes during that process.
Lastly, I've not written a real program in well over a decade (except for shell scripts, but that doesn't count), so it didn't matter which language I used to write the converter - except for the fact I couldn't really remember any enough to start writing code, other than C, C#, and java. So java it was. Please note that this code is a great example of voodoo programming. (throw random stuff together until it seems to work)
Last technical note - when the encoded color values came out as a single byte - I had to convert them to a unicode character by flipping the msb so it would encode properly. It seems to have worked.
Thanks to Mike for having the patience to answer my questions on this unsupported feature.
PS: future readers - this is good for pleco v3. It will almost certainly not be correct for v4