Optimize logos #328
No reviewers
circlebuilder
xy
Labels
No labels
Bug
C2S
Community
Core Spec Decision
Discussion in Forum
Extra Spec Decision
Meta Bug
Meta Decision
Meta Website
Need Feedback
Spec Docu
Spec Wording
Style
Waiting on Dependency
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
ForgeFed/ForgeFed!328
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "dustdfg/ForgeFed:logos"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Continuation of #327
Currently blocked by waiting for answer https://gitlab.com/inkscape/inbox/-/issues/12900
Thank you @dustdfg! The logo-with-margin shows part of a line sticking out at the bottom of the logo.
@circlebuilder wrote in #328 (comment):
Yeah. Thanks! It wasn't visible in the logo without margin due to viewbox cutting it so I just decided it is ok. And then ctrl+c, ctrl+v... Thanks for pointing it. Logo with text has actually the same issue
7f25292a9bto57fff19853Sticking line is solved
Different spacing in text from linked issue is caused by the fact that inkscape and browsers handle white spaces differently. Should be okay if just remove all white space chars from text element. Solved
the only problem now is adjusting text elements to original image
I think you forgot to do a 'text to curves' (which I do too regularly) or other way to embed/refer to the font in use..
@circlebuilder wrote in #328 (comment):
Yeah, I know what I do. It is still WIP and so I just use the same filename to see how it looks in a codeberg preview. Which to be honest is not trustworthy because if I change scale of the page I get different results in rendering of that preview. I was going to move that file to another filename and use text embedding for the existing name (option 1. see below)
I hate when someone carelessly embeds text and you just get questioning what is the font. IIRC in newer inkscape versions it saves this info. But I needed to try font one by one to find necessary. I hate it.
Btw, I was going to ask it a bit later or even but as you brought it now... What way do you want I use?
visibility="none"First two will preserve info about offsets of each character. The third will use the default of font. Currently the characters are shifted a bit without aligning them manually so either font was changed over time or the letters were adjusted (maybe manually, maybe throughout floating pointer error accumulation in inkscape)
I usually use option 1) where I do a text-to-curves + SVGOMG optimization. I has the disadvantage of having to keep the two files in sync, but when sharing the optimized versions ensure at least everywhere they look as intended. Though 2) is creative I think I prefer it to the other options.
57fff19853toa1e61d78f7a1e61d78f7toe79c5884e2e79c5884e2to71f1a5d6fb71f1a5d6fbto06faab557a06faab557ato3ff9aa8ee83ff9aa8ee8toed6460c082ed6460c082to9014656e50It is quite strange bug of preview. I think I will try to figure out if it is firefox related or not tomorrow...
So first of all preview (both overlay and swipe) of text version shows me that my version is slightly wider than original version. Which happens at 100% zoom. Then when I zoom it in to max and interact with preview it shows another artifacts: last character is a bit out of place or letters have slightly different size. Zooming out back and interacting with preview gives now possibly first or second or mix of both behaviors (the third option is almost impossible to catch). And bug behaves identically if there is a text element or just a path. What is strange that artifact differ between text element and paths... But for paths it is more stable, usually the last d character shows in different size.
Wtf??? Inkscape shows 3 images similarly original, my text and my paths but browser shows them all differently and rendering of each one changes when you change scaling of the page
The same results if I just open the files as two tabs in browser and quickly jump from one to another. The bigger scale of page the smaller differences...
@circlebuilder Please can you look at preview in browser and say if you have the same thing? I've pushed there version with so there is no problem with font missing
Maybe it is all because there is used viewbox in original version which is used for scaling :/
I did everything in Inkscape by zooming to max and aligning everything by hand. Actually twice. First time before I wrote in previous message that there is only left adjusting text to original image. It makes me crazy. I am not sure what is to consider correct rendering because lots of image viewers give similar results to browser.
I "love" text. It has always been "reliable" on its own... I love inkscape for bluntly using scale on viewbox when user decided to change units to px because no one uses mm as default :|
I don't think I currently experience those issues you mention. It is a bit hard to gauge, as the imgs look like below, but it looks okay in terms of scaling and these artifacts.
Yeah, it included copy of original text too, sorry. Now it should be ok...
d29bd1d7a4toa63f76b7d1New commits pushed, approval review dismissed automatically according to repository settings
WIP: Optimize logosto Optimize logosFinally I've squashed test commit, optimized embedded text with svgo, checked if it is ok... Now it is really ready. I even thoroughly looked at preview of just rects and they have the artifacts too which disappear when I change page scale. It is absolutely ok in Inkscape though so I think it is ok.
Thanks for the PR!