-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Symbol Translation - Allow each colour to have it's own symbol #33
Comments
Thanks for opening issue, For consistency, initial discussion about this started here. We decided to isolate this behavior into a new issue since it could be deals with independently of current export types. |
Symbols are used by the Diamond Painting / 3d painting community as well. I'm not sure if there's a standard or not, but there appears to be a mostly standardized set of symbols associated with DMC colors. |
Oh interesting, can't say I have tried Diamond/3d painting myself but I took the idea from a piece of cross stitching software I used when creating charts from images. I didn't pay enough notice to whether or not colours had their own distinct symbols (ASCII ones in the cross stitching software I used). I'd be interested to see if other brands did it (I used DMC thread when cross stitching so it could be something they did specifically). I definitely think it's a good way of making different colours distinguishable in an easy to recognise way. If you did it long enough too you might get to a point where you don't need a key 😄 |
Hey @maxcleme , I've spent a few days studying the project in order to get a grasp on it and how all the pieces tie together. I must admit the majority of the WebGL stuff still throws me a little but I can try and tackle that at a later point. I wanted to get your opinion on where you think the symbols should be stored? I've been in two minds about if they should be in this repo or your colour one. Initially I thought the colour one would be ideal but I've noticed that the API might have to change a little if we did that. It could however be handy for other people who might want to take advantage of that functionality in the future. Just wanted to get your thoughts? Cheers! |
Hey!
Sorry for short answer (I don't have my laptop to make links etc).
I think the 'best' place would be in the color repo, since it handle
different version/format in order to not break anyone, we could create a v3
which associate a unique symbol to each color. Doing this way will prevent
headache in beadifier since we would 'only' to use another field instead of
the 'ref' one!
The generation in the color repo is done in Go, I can easily give you a
hand if you struggle with the algorithm.
Did you find some solution matching my previous statements? Regarding
uniqueness/reproducibleness?
Cheers!
…On Tue, Jul 7, 2020, 18:37 Jamie Sykes ***@***.***> wrote:
Hey @maxcleme <https://github.com/maxcleme> ,
I've spent a few days studying the project in order to get a grasp on it
and how all the pieces tie together. I must admit the majority of the WebGL
stuff still throws me a little but I can try and tackle that at a later
point.
I wanted to get your opinion on where you think the symbols should be
stored? I've been in two minds about if they should be in this repo or your
colour one. Initially I thought the colour one would be ideal but I've the
API might have to change a little if we did that. It could however be handy
for other people who might want to take advantage of that functionality in
the future.
Just wanted to get your thoughts?
Cheers!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2QNGKR4HXYL76GWJJFU33R2NFOJANCNFSM4OBTPVPQ>
.
|
Cool, I'll create a separate issue in the Color Repo, have a bit of play over the next few days and get you an initial PR over. I took a look into a number of icon packs and whilst Font Awesome seemed like a good choice, I'm not sure about if there will be enough. It has around 1500 icons but a large number of them I'd say probably aren't ideal to use (brand icons, battery indicators etc). The other icon packs were either paid or didn't have quite enough icons (around the 400 mark). I'm wondering if something like this might be another alternative (https://lonewolfonline.net/html-character-codes-ascii-entity-unicode-symbols/). Using unicode symbols instead from doing a rough count I got 931 items, which I think should be enough and would make things a lot simpler (no need to figure out how we get svg's etc across. What do you think? |
Definitely no brainer if we can use Unicode symbol instead of something proprietary. Great catch! |
Of course, but I guess using Unicode means symbol define in the standard,
not all the characters which obviously would generate unwanted similar
pattern. But damn we could even use Emoji 😂
…On Wed, Jul 8, 2020, 16:51 Dave Palay ***@***.***> wrote:
Just a warning on using Unicode, you will need to be careful of similar
characters. For example:
[image: image]
<https://user-images.githubusercontent.com/33780/86933731-7aa4c180-c100-11ea-96a1-02475485c4ff.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2QNGPBZJRMQ5NY6B4TNILR2SBVNANCNFSM4OBTPVPQ>
.
|
Good spot @dpalay I might have to try and pull those out and see how many we would have. @maxcleme I did think about Emoji but I'm not sure if they are too complicated/detailed to fit into a small area? Perhaps when I get into it, I might change my mind. maxcleme/beadcolors#12 - I just created this issue over on the colour repo to discuss this. Maybe we can move this discussion over to there and keep this issue for discussions about this specific repo? |
Honesty, Emoji idea was for fun, I don't think we end up with something
usable 😂
…On Wed, Jul 8, 2020, 18:26 Jamie Sykes ***@***.***> wrote:
Good spot @dpalay <https://github.com/dpalay> I might have to try and
pull those out and see how many we would have.
@maxcleme <https://github.com/maxcleme> I did think about Emoji but I'm
not sure if they are too complicated/detailed to fit into a small area?
Perhaps when I get into it, I might change my mind.
maxcleme/beadcolors#12 <maxcleme/beadcolors#12>
- I just created this issue over on the colour repo to discuss this. Maybe
we can move this discussion over to there and keep this issue for
discussions about this specific repo?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2QNGOM7A64X7KSK2L2UITR2SMZRANCNFSM4OBTPVPQ>
.
|
Yeah, I don't think so either. Sorry the joke in that comment about Emojis went straight past me 😂 |
@maxcleme Just wanting to pick this back up again after making the change to the color API earlier this week. I'm wondering if the symbols functionality would be better suited for print/export only and shouldn't appear on the preview for beadifier. I put together this quick mockup with the image on a small pixel art image (60 x 58). Due to the sizing of everything you loose the symbols anyway so I'm wondering if this option should perhaps be available on the export page or at least only do anything from the export page? Keen to hear your thoughts before I start the main implementation. Cheers. Edit: Just thought I'd add that this mockup was done using canvas only rendering, might be different using webgl. |
Thanks for doing such mockup, really nice to see what I may looks like before even starting implementation. Regarding your question I have to say that IMO it should be a toggle in the "Advanced", controlling both exports and previews (maybe?). I don't see how it could be useful without being in exported file, I dunno either how really people use this project but I highly doubt they bead using only the preview. The preview seriously lacks of feature I would like to in order to be fully usable without exporting patterns, (eg: ability to check bead color atomically, save current project in local storage or as a file, being able to open it later on, etc). Doing small pattern (smaller than a 29x29) may be done using the preview, but above that I highly doubt it. If we want to implement this everywhere, here the point I think we have to tackle :
I have to say that for renderers I don't even know if we want to display symbols, currently there is no references at all in the preview, is it something that also you that bother you (honest question)? |
I have to agree a toggle in the advanced section is the right place to put it. I share that opinion about it not being useful in the preview but thought I would double check with you anyway. I think we should keep the preview as it is and purely use the option to show symbols inside the export. No it doesn't bother me that we don't have it in the preview window to be honest, I export and print the patterns out anyway. I'd say that would come under a separate issue and can be looked at if it gets flagged at a later point. If that's ok with you? I think for me at least this is enough to go on and I'll aim to get something over to you to review in the next few weeks. |
@jaymeh Done in v.1.12.0 If everything is fine, feel free to close the issue :) |
Thank you |
It would be good as part of the export process if each colour had a unique symbol associated to it. This would give a unified way of showing colours across various brands and potentially save on the amount of space on the page each peg needs.
Using symbols instead of colour names could be use in all types of export and could potentially be something toggled in the Advanced tab.
I have attached a mockup here from a tool I am working on which demonstrates this functionality.
squirtle-pattern.pdf
It's been discussed that maybe FontAwesome or a similar tool is used for the symbols as there are a large number of symbols so we can be sure that each symbol can be made unique to the number of colours across all manufacturers.
The text was updated successfully, but these errors were encountered: