The new svg files are a new logo proposal from me. See Codeberg/Design#3
It should look something like this:
The new svg files are a new logo proposal from me. See https://codeberg.org/Codeberg/Design/issues/3#issuecomment-55937
It should look something like this:
Hm, seems like this breaks the favicon & the logo:
That seems to be a bigger issue as it relates to lots of stuff in the Makefile. @hw maybe we want to convert the images manually instead of with the Makefile? It seems to me like the logo changes very rarely & if it changes the change will be that drastic that the logic needs to change too...
Hm, seems like this breaks the favicon & the logo:
That seems to be a bigger issue as it relates to lots of stuff in the Makefile. @hw maybe we want to convert the images manually instead of with the Makefile? It seems to me like the logo changes very rarely & if it changes the change will be that drastic that the logic needs to change too...
The convention for the master SVG was to put things that show up in different sizes only onto layers layer2 and layer3:
For large pictures, all layers are rendered,
for medium size, layer3 is removed,
for small size (favicon etc), both layer2 and layer3 are removed.
The convention for the master SVG was to put things that show up in different sizes only onto layers `layer2` and `layer3`:
- For large pictures, all layers are rendered,
- for medium size, `layer3` is removed,
- for small size (favicon etc), both `layer2` and `layer3` are removed.
--export-area-drawing does the trick. If this doesn't work with the new content for any reason, using your approach of separate images instead of layers works perfectly well, too. What would you prefer?
`--export-area-drawing` does the trick. If this doesn't work with the new content for any reason, using your approach of separate images instead of layers works perfectly well, too. What would you prefer?
I think I'd prefer to avoid SVG conversion with Inkscape completely, as it's probably the least portable of the whole deployment process. ImageMagick works well in the command line, on headless servers and in Docker, but Inkscape requires so many dependencies that automating it would be pretty complex...
But, if we want to keep it, I guess the layer-based approach is fine too.
I think I'd prefer to avoid SVG conversion with Inkscape completely, as it's probably the least portable of the whole deployment process. ImageMagick works well in the command line, on headless servers and in Docker, but Inkscape requires so many dependencies that automating it would be pretty complex...
But, if we want to keep it, I guess the layer-based approach is fine too.
Inkscape on headless works via xvfb-run, lots of dependencies tho and not sure how stable the API is. ImageMagick would be cool but lacks good SVG support.
No strong feelings, either approach is fine: happy to merge if you say it's time to do so.
Inkscape on headless works via xvfb-run, lots of dependencies tho and not sure how stable the API is. ImageMagick would be cool but lacks good SVG support.
No strong feelings, either approach is fine: happy to merge if you say it's time to do so.
I'd prefer if @mray could add a "codeberg-dark.svg" without text (I can't commit to this PR branch), that should require the least amount of work on all sides right now.
I'd prefer if @mray could add a "codeberg-dark.svg" without text (I can't commit to this PR branch), that should require the least amount of work on all sides right now.
Oh, and I've now thrown out Inkscape completely from the Makefile in #16, which means that the SVGs now need to be cropped already (File, Document settings, Crop to contents (or something similar)).
Also, in the attachment in Codeberg/Design#3 the logo has a white background on the circle for the light version on dark background. This would be relevant for the favicon in a dark-themed browser.
Oh, and I've now thrown out Inkscape completely from the Makefile in #16, which means that the SVGs now need to be cropped already (File, Document settings, Crop to contents (or something similar)).
Also, in the attachment in https://codeberg.org/Codeberg/Design/issues/3#issuecomment-55937 the logo has a white background on the circle for the light version on dark background. This would be relevant for the favicon in a dark-themed browser.
I'd prefer if @mray could add a "codeberg-dark.svg" without text (I can't commit to this PR branch), that should require the least amount of work on all sides right now.
Here I attached an svg that looks just like this:
Just let me know when you need different versions or sizes. Hope it helps.
> I'd prefer if @mray could add a "codeberg-dark.svg" without text (I can't commit to this PR branch), that should require the least amount of work on all sides right now.
Here I attached an svg that looks just like this:
Just let me know when you need different versions or sizes. Hope it helps.
You should be able to upload it directly at https://codeberg.org/mray/build-deploy-gitea/src/branch/new-logo. The PR always refers to a branch, so when you commit a new file to the branch, the PR will also reflect the changes.
The new svg files are a new logo proposal from me. See Codeberg/Design#3
It should look something like this:
Hm, seems like this breaks the favicon & the logo:
That seems to be a bigger issue as it relates to lots of stuff in the Makefile. @hw maybe we want to convert the images manually instead of with the Makefile? It seems to me like the logo changes very rarely & if it changes the change will be that drastic that the logic needs to change too...
If you add a
codeberg-light.svg(codeberg.svgwithout the text), this should work.The convention for the master SVG was to put things that show up in different sizes only onto layers
layer2andlayer3:layer3is removed,layer2andlayer3are removed.Hm, does it cut the document to its contents automatically?
--export-area-drawingdoes the trick. If this doesn't work with the new content for any reason, using your approach of separate images instead of layers works perfectly well, too. What would you prefer?I think I'd prefer to avoid SVG conversion with Inkscape completely, as it's probably the least portable of the whole deployment process. ImageMagick works well in the command line, on headless servers and in Docker, but Inkscape requires so many dependencies that automating it would be pretty complex...
But, if we want to keep it, I guess the layer-based approach is fine too.
Inkscape on headless works via xvfb-run, lots of dependencies tho and not sure how stable the API is. ImageMagick would be cool but lacks good SVG support.
No strong feelings, either approach is fine: happy to merge if you say it's time to do so.
I'd prefer if @mray could add a "codeberg-dark.svg" without text (I can't commit to this PR branch), that should require the least amount of work on all sides right now.
Ehm, I obviously meant codeberg-light.svg ,
ok
Oh, and I've now thrown out Inkscape completely from the Makefile in #16, which means that the SVGs now need to be cropped already (File, Document settings, Crop to contents (or something similar)).
Also, in the attachment in Codeberg/Design#3 the logo has a white background on the circle for the light version on dark background. This would be relevant for the favicon in a dark-themed browser.
Test: #16 (see Codeberg/Community#189)
Alright, I have no idea what that was... I meant the attachment in Codeberg/Design#3
Here I attached an svg that looks just like this:
Just let me know when you need different versions or sizes. Hope it helps.
hm… gitea seems to not like the attached svg next to a png? next try:
Gitea does not allow the file extension to be uploaded. :(
You should be able to upload it directly at https://codeberg.org/mray/build-deploy-gitea/src/branch/new-logo. The PR always refers to a branch, so when you commit a new file to the branch, the PR will also reflect the changes.
Ok thanks. Did just that.
Okay, I added some smaller fixes in #16. This can be merged now, then I'll rebase #16 onto master so that one can be merged too. :)
6ad666eb14.