A dictionary of colors

mikelove

皇帝
Staff member
#2
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)
 
#3
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)
Can someone give instructions on how to either:
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.
 
#5
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
 

Attachments

Last edited:
#6
this worked on a much older version of pleco for android.

i believe mikelove has changed the color code syntax in more recent versions, and now it doesn't work.


Disregard. My original `colors.txt' and agewisdom's `Colour.pqb' both work correctly on Pleco 3.2.61 for Android.
 
Last edited:
#7
#8
Has anyone gotten this to work?

I've tried bringing in the QDB file, and importing the text file, but the colors come out all wrong for me.

This is under the 3.2.25 version of Pleco in the Apple IOS.
 
#9
Hmmm... It works on most of the colors like red, yellow and black for me. But I'm on Android. Maybe someone else more familiar with PLECO and IOS can check.
 

mikelove

皇帝
Staff member
#10
Android and iOS use different systems for representing numerical codes in text - this was not something we designed to be user editable :) - so you'd need to make a different version of the file with iOS' numerical representation system to have it work on that.
 
#11
ah. that would explain it.

Could you give me a hint as to what the representation is so I could edit the file for is iOS users?

Yes, I know the need for this will all go away with v4, but until v4 arrives - I'd like to have something to look at until then.
 

mikelove

皇帝
Staff member
#13
Yes, I know the need for this will all go away with v4, but until v4 arrives - I'd like to have something to look at until then.
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.
 
#15
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
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>
 

mikelove

皇帝
Staff member
#16
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)
 
#17
That all sounds like very sensible design decisions.

Did I mention that I can't wait for v4 and that I'm really looking forward to the new features?
 
#18
That all sounds like very sensible design decisions.

Did I mention that I can't wait for v4 and that I'm really looking forward to the new features?
Me too. I wish I hadn't though... cos we might be liable to wait another year for it to come out...
Wait... isn't 2019 just around the corner? :D
 

mikelove

皇帝
Staff member
#19
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.
 
#20
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
 

Attachments

Top