User talk:TSamuel

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Unblocking User_talk:2600:1:9000:0:0:0:0:0/36[edit]

Unblock request declined

This blocked user asked to be unblocked, but one or more administrators has reviewed and declined this request. Do not remove this unblock review while you are blocked. Other administrators can also review this block, but should not override the decision without discussion.

Request reason: "This also blocks logged-in long-time users who happen to mobile edit from Sprint (now T-Mobile) IP blocks (like myself). This seems a bit too wide to what you're trying to accomplish. Could you pare this block down to something reasonable? TSamuel (talk) 18:37, 2 August 2020 (UTC)"[reply]
Decline reason: "Procedural decline: Your account is not blocked. ✓ Done however is an alternation of the range block; it should no longer impact logged in users. Эlcobbola talk 15:54, 3 August 2020 (UTC)"[reply]
Administrators: This template should be removed when the block has expired.
 (Block log)
(unblock)
(Change local status for a global block)
(contribs)

Deutsch ∙ English ∙ español ∙ français ∙ hrvatski ∙ magyar ∙ Plattdüütsch ∙ português ∙ Simple English ∙ Tiếng Việt ∙ suomi ∙ svenska ∙ македонски ∙ русский ∙ हिन्दी ∙ 日本語 ∙ 中文（简体） ∙ 中文（繁體） ∙ 中文（臺灣） ∙ +/−

That works. Thanks very much! 🙇🏾‍♂️ TSamuel (talk) 05:03, 4 August 2020 (UTC)[reply]

File:One Ring inscription-Tolkien-jpeg.jpg[edit]

File:One Ring inscription-Tolkien-jpeg.jpg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Afrikaans ∙ Bahasa Indonesia ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 中文 ∙ 中文（简体）‎ ∙ 中文（繁體）‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

— Draceane talkcontrib. 13:25, 6 October 2020 (UTC)[reply]

File:R rotunda in different fonts.png[edit]

File:R rotunda in different fonts.png has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Afrikaans ∙ Bahasa Indonesia ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 中文 ∙ 中文（简体）‎ ∙ 中文（繁體）‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

Joaopaulo1511 (talk) 01:16, 1 November 2020 (UTC)[reply]

File:Brorphine structure.png[edit]

File:Brorphine structure.png has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Afrikaans ∙ Bahasa Indonesia ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 中文 ∙ 中文（简体）‎ ∙ 中文（繁體）‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

Leyo 21:52, 27 July 2021 (UTC)[reply]

File:Mephedrone.png[edit]

File:Mephedrone.png has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Afrikaans ∙ Bahasa Indonesia ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 中文 ∙ 中文（简体）‎ ∙ 中文（繁體）‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

Leyo 21:55, 27 July 2021 (UTC)[reply]

File:Diborane-2D.svg[edit]

File:Diborane-2D.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Afrikaans ∙ Bahasa Indonesia ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 中文 ∙ 中文（简体）‎ ∙ 中文（繁體）‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

Leyo 08:35, 27 October 2021 (UTC)[reply]

Explanation?[edit]

Did you have a particular reason for replacing this image with a reduced-resolution version? DS (talk) 16:27, 20 November 2021 (UTC)[reply]

It's not reduced resolution. The original was not efficiently compressed, even by 2007 standards, & modern tools make it possible to do even better than what was possible then. TSamuel (talk) 05:19, 21 November 2021 (UTC)[reply]
Out of curiosity, what method did you use for the compression? Because when the smaller-filesize image is opened in Photoshop 2021, the result is... strange. DS (talk) 16:26, 21 November 2021 (UTC)[reply]

I used https://compress-or-die.com/jpg . Photoshop's "vintage" compression engine hasn't kept up with the times, either, so there is a compatibility toggle there under "Expert" mode, but it isn't needed for anything coded w/in recent years. Adobe just doesn't seem to care about that anymore. TSamuel (talk) 03:12, 27 November 2021 (UTC)[reply]

Careful recompression[edit]

Whatever "careful" is supposed to mean – it is quite destructive. You mainly reduce precision, to a degree where it causes very visible distortions. Even just for viewing I'd like to have at least 10x (one digit) more resolution. But we also want files on Commons to be useful for derivative works, so typically we'd like to retain the original resolution.--Reseletti (talk) 18:41, 28 December 2021 (UTC)[reply]

I do try very hard not to allow any visible distortions. In the instances it doesn't quite work, I do appreciate a rollback w/ a specific note, & I can work to do better. But too much precision (NOT resolution, as that's not particularly relevant for the vector images I generally work on) does make derivative works more finicky (less portable, as more dependent on how whatever renderer chooses to handle such), so I'm very mindful about it. Thanks very much for the note. 🙇🏾‍♂️ TSamuel (talk) 00:18, 29 December 2021 (UTC)[reply]
margin too big   (also File:U+2145.svg)
Please stop doing this, unless you can be sure not to change the resulting images. On the right you see some examples, where each symbol should fill the image with no or minimal margin. (In case of ½, you have already tried to fix it, but it is still absurdly wrong.) Also you have cut of parts of images - see here and here. (In the latter image there is also an issue with the edge lengths around node 19.)
I see no need for these compressions at all. (Is there any tangible advantage?) If you for some reason want to do them, you should actually render PNG files from your versions, and make sure they are equal to those of the current version. Whatever "verified via SVGCheck" entails, it is obviously not good enough. --Watchduck (quack) 10:05, 20 March 2022 (UTC)[reply]
SVGCheck is https://svgcheck.toolforge.org/ so WM's test SVG renderer. As for the rest, please feel free to revert or edit if the updated version isn't acceptable. Also, a revert mentioned "image size." As you might not be aware, dimensions of an SVG are basically irrelevant, as they're meant to be rendered perfectly at any arbitrary size chosen (especially nowadays with a huge variety of, e.g., screen sizes), so I'm not understanding where the problem lies.
TSamuel (talk) 13:44, 20 March 2022 (UTC)[reply]
It is not important if an image is 100 or 1000 pixels wide. But of course it is important, when you introduce big margins, or cut of parts of the image. (Just look at your version in the history of this file, and you can see that the top and bottom vertex are cut of.) It is your responsibility not to make bad changes, and to revert them if you do. Please do so for the Tex images shown above, and please make sure that this does not happen in the future. --Watchduck (quack) 19:30, 20 March 2022 (UTC)[reply]

Yep, I see them. Let me see if I can fix, else I'll revert. TSamuel (talk) 19:37, 20 March 2022 (UTC)[reply]

I'd have to argue that replacing SVG versions of Unicode characters with SVG that just contains the character as a <text> element actually makes the images less portable, because the image will become useless to anyone whose computer does not have that symbol available, and may render weirdly (and always unpredictably, by design) when embedded in a document, because there's not commonly accepted size for these symbols (unlike for Latin alphabet when assuming a font with Helvetica/Times-compatible metrics is going to be used).
Btw, reverted File:Qwerty.svg because of double-escaped entities.
Additionally, native SVG size is relevant for generated preview images in the file page. If you shrink an image that has text in size, it will become harder to read in the preview page, at least in desktop view, like in File:BitfieldsSLN.svg.
Another example where size change breaks an article layout unexpectedly is currently present at w:BMP file format#Example 1 (screenshot). Curious Walrus (talk) 14:43, 23 March 2022 (UTC), edit: Curious Walrus (talk) 15:16, 23 March 2022 (UTC)[reply]
- I'll revisit those Unicode characters. You're probably right, but I have to think it over. Especially since assuming anything is a default/specific font/size anyplace is problematic.
- I don't understand the problem w/ the "double-escaped entities." Could you clarify?
- Wikimedia SVG rendering has many problems, due to it's outdated rendering engine. IIRC, this text problem is a known issue, but happens inconsistently (again, IIRC) based on which prerendered raster image is chosen. I myself don't see it, but, admittedly, most of my online consumption is via mobile.
- Layout problems for vector images need to be handled by adjusted the size as per the directions @ Wikipedia:Wikipedia:Extended_image_syntax#Brief_Syntax, taking careful note that, practically, there actually isn't a fixed layout for anything on Wiki*edia, given, e.g., the vast array screen sizes, browser rendering engines, &c, so that pixel-based sizing is deprecated (like what you're asking to keep) per Wikipedia:MOS:IMGSIZE. If layouts wherever are "correct" (for yourself, for example) using pixel-sizing, they're certainly broken for others, so the images were not correctly sized in the including page via the Wiki syntax. IIUC, it's best to solve as the above guidelines mandate.
Thanks very much for asking so nicely & thoughtfully! 🙇🏾‍♂️ TSamuel (talk) 00:15, 24 March 2022 (UTC)[reply]
1. Double-escaped entities: the button which previously read " / ' reads in your optimized image as &quot; / &apos;, external screenshot. It shows up a) before revert, in prerendered raster images; and in b) Firefox, c) Chrome, and d) Safari too, when viewing the SVG (optimized version) directly.
2. I'm not sure which text problem you are referring to. At least the one in File:Qwerty.svg happens with the raw file too, like said, so it's a problem with the SVG file, not with the outdated rsvg-convert. It's about turning &quot; to &amp;quot; in the code (hence: double-escaping), and I assume one of the optimizers you are using does that.
3. Fair enough, but it would be nice if you checked if pages using the image were relying on the default size being something, especially if you're "resizing" a small image (especially the ones smaller than or close to the 220px base width) by a considerable factor (about 4x in this case. I assume width=512px is a default from server for SVGs without default size?). If it breaks (i.e. alters layout significantly in desktop view) one page, it would be easy to fix at the same time; if it breaks multiple pages, maybe keep the original size information? Anyway I don't quite see why the original size information has to be stripped from the SVG, it's just about 24 bytes and may be useful when reusing the file, especially if there are multiple images that are meant to be used together.
Curious Walrus (talk) 08:29, 1 April 2022 (UTC)[reply]
+1 -- Tuválkin ✉ ✇ 16:07, 1 April 2022 (UTC)[reply]

Source-only SVG optimisation[edit]

Please don't compress SVGs unless the filesize reduction is non-trivial (say, ≥ 1 MBs), because:

1. It degrades readability of files whose source code has been cleaned up using a text-editor (as BMPfileFormat.svg was, along with every other vectorisation I've uploaded to Commons).

2. Wikipedia renders PNG versions of SVGs for the express purpose of optimising page loading speed, the very reason SVGs are optimised like this in the first place. So the reduction to filesize will only ever become relevant after a user opens the original file; at which point, ~15-30 KBs less is barely going to be noticeable even over a slow connection.

3. Wikimedia's guidelines on SVGs explicitly discourages this practice, listing three additional reasons why such "optimisations" are to be avoided unless the change brings a visible improvement to the image.

— Alhadis (talk) 05:08, 20 March 2022 (UTC)[reply]

1. The original sources are easily accessible in the previous file versions for anyone who wants them for any reason.
2. There is ongoing discussion that's leading towards directly rendering the SVGs when referenced, as least via user preference, so these small filesize changes will become relevant as part of a whole page, as web images generally are.
3. That page starts with "This page is an essay; it contains the advice and/or opinions of one or more Commons contributors. It is not a Commons policy or guideline, and editors are not obliged to follow it. Please update the page as needed, or discuss it on the talk page." As such, I make changes as makes common sense, not whatever strange conclusion that increasingly-outdated page somehow states. TSamuel (talk) 13:52, 20 March 2022 (UTC)[reply]
Please use the usual indentation to keep talk pages readable. Commons:Talk_page_guidelines#Layout
I do not understand what advantage your compression is trying to achieve. You are not saving disk space, because the old versions are kept. And you are forcing the system to re-render the images in all sizes, which have been rendered and cached before. Are you sure you are actually improving something for anyone? --Watchduck (quack) 19:47, 20 March 2022 (UTC)[reply]
Hmm, the mobile-default non-wiki conversation view seems to have an indenting bug. I wonder where it might be filed.
As for the size optimization (not technically compression, since, sadly, WM doesn't support SVGz), you might realize there's an entire Internet outside of just Wiki*edia academics. Indeed, per https://wikimediafoundation.org/our-work/commons/, "Wikimedia Commons has become a 'go-to' source on the internet—used by everyone from casual browsers to major media outlets to educational institutions, and easily discoverable through search engines." So I help by making poorly optimized images more useful overall. TSamuel (talk)
I agree with Alhadis: just don't do that anymore. Please. - Erik Baas (talk) 23:08, 27 March 2022 (UTC)[reply]
Sadly, disagreeing w/ me doesn't change WM policy, as I detailed above. I'll quote myself in the other section, just in case you missed it. TSamuel (talk) 23:19, 27 March 2022 (UTC)[reply]
1. Legitimate modifications will be made to the latest version of an image, meaning the unmangled version becomes outdated.
2. Even if Wikipedia does serve the original SVG as part of a page, on-the-fly compression (e.g., gzip, Brotli) will render most source-only optimisations irrelevant. For example, here's a filesize comparison of the obfuscated copy of BMPfileFormat.svg you uploaded, with and without gzip compression:
File version Uncompressed size Gzipped size Ratio of original
Original 32,593 bytes 6,024 bytes 18.48%
Obfuscated 23,918 bytes 4,957 bytes 15.21%
That's barely over a kilobyte of difference (1,067 bytes). And we haven't even considered more powerful compression algorithms such as Brotli, which might be in-use by Wikipedia's servers in future.
3. Most of that article is still relevant, particularly the section concerning source-only optimisation.
4. Finally, clobbering a file tagged with {{NoInkscape}} is just plain disrespectful to its author, irrespective of filesize. Alhadis (talk) 06:22, 30 March 2022 (UTC)[reply]
1. The next version can be reoptimized at will (with thanks to the new editor) just as any other outdated file.
2. So? Talking about what may or might happen via how a file could be served at a lower layer doesn't matter for this.
3. It's only relevant if 1 agrees w/ its options, which aren't universal, even per its Talk page.
4. Did you happen to thoroughly read that template page? It speaks of not adding garbage to SVGs (via various software, with some examples given), with the induction that taking such out is a service to whomever tagged it, which is precisely what I do.
Thanks very much for your civility. I utterly appreciate it. 🙇🏾‍♂️
TSamuel (talk) 01:52, 31 March 2022 (UTC)[reply]
I have to agree with the previous commenters here. Obfuscating (by optimizing whitespace, comments and other stuff away) a hand-crafted SVG is functionally equivalent to "adding garbage", even though technically nothing is added there. Now, if someone 1. edits the optimized version and 2. someone else wants to edit it later, they have to either use the outdated readable version and redo the later edits, or try to make sense of the most recent obfuscated version. It significantly impairs the editability of the files, even if it (allegedly) makes them more reusable in some other ways. And Wikipedia is all about editing. Curious Walrus (talk) 08:42, 1 April 2022 (UTC)[reply]
1. No, the original (hand-written) version is lost. Comments, formatting, and other techniques used by authors for communicating their intent to readers, can't be recovered short of manual intervention by the author. For a more potent example of where this is important, see File:Chrom_-_Trend_Förderung.svg or Category:Structured_SVG.
2. How? The user is served a payload of roughly the same size. You mentioned SVGZ files; they're no different to a "vanilla" SVG file transferred with gzip compression (save for the annoying caveat that an SVGZ file's contents are pre-compressed).
3. Judging a page's relevance on how many users have updated it to voice their agreement is, quite frankly, rather silly. Furthermore, you're dismissing some rational and objective points about tickling watchlists, wasting server resources, and adding pointless churn to file history lists.
4. As per point 1 above (along with everything @Curious Walrus said), SVGs designed to be read and edited in source form use comments, whitespace, and other so-called "garbage" for enhancing readability, facilitating editing, and generally upholding maintainability. This is a far cry from the garbage generated by image-editing software (which will never be as efficient as code written by SVG-literate authors).
As for the "garbage" that template page refers to… well, not every suboptimal SVG merits optimisation. Consider Inkscape SVGs, which encode objects with no equivalent SVG representation using editor-specific attributes; e.g., spirals, stars, 3D boxes, and other complex shapes that can be manipulated parametrically. Unless this data affects the SVG's appearance when viewed in browsers, it's worth keeping such cruft intact so other Inkscape users can edit the file more efficiently.
You're welcome. Please be more mindful when optimising SVGs. Your time is better spent optimising files flagged for cleanup. Alhadis (talk) 13:17, 5 April 2022 (UTC)[reply]

File:L_substitution_tiling.svg[edit]

Hi TSamuel, I noticed you compressed File:L_substitution_tiling.svg. Removing whitespace makes the file very hard to read and edit in the future. If there are any changes to be made, can you please keep the indentation? Thanks, cmɢʟee ⋅τaʟκ 11:16, 24 March 2022 (UTC)[reply]

Respectfully, keeping indents (& even whitespace) is just inefficient when building an image for the web, especially when it's so easy in this image to use a tool to make easier to read if needed. See, for example, the WM-linked validator w/ the HTML-Tidy option, which not only points out errors in the filter logic, but makes the file quite easy to follow.: https://validator.w3.org/check?uri=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F0%2F0b%2FL_substitution_tiling.svg&charset=%28detect+automatically%29&doctype=Inline&ss=1&outline=1&group=1&No200=1&verbose=1&st=1&user-agent=W3C_Validator%2F1.3+http%3A%2F%2Fvalidator.w3.org%2Fservices
TSamuel (talk) 12:42, 26 March 2022 (UTC)[reply]
"inefficient " is not an argument: some of us create and edit svg files with a text editor. Your edit made this one unreadable, so I reverted the file to its previous version. - Erik Baas (talk) 23:05, 27 March 2022 (UTC)[reply]
You're not merely compressing some whitespace, you're also altering the logical order of <defs> and renaming the descriptive ids to meaningless letters. Contrary to what you seem to argue, the transform is not lossless, and beautifying the XML file does not restore the editability of the file. Deleting embedded metadata such as <title> and <desc> tags is also destructive. Curious Walrus (talk) 09:20, 1 April 2022 (UTC)[reply]

Please undo your change on File:75_percent.svg[edit]

I do not understand why you changed the dimensions of this picture file. This has a negative effect for example on page [1].

Could you please cancel it?

Thanks in advance!

--FreeCorp (talk) 22:04, 27 March 2022 (UTC)[reply]

The same goes for dozens of pages on nl.wikibooks (including the front page!!) so I reverted the file to the previous version. Please don't ever change the dimensions of any svg fle. - Erik Baas (talk) 22:54, 27 March 2022 (UTC)[reply]
As I mentioned in a different section, layout problems for vector images need to be handled by adjusted the size as per the directions @ Wikipedia:Wikipedia:Extended_image_syntax#Brief_Syntax, taking careful note that, practically, there actually isn't a fixed layout for anything on Wiki*edia, given, e.g., the vast array screen sizes, browser rendering engines, &c, so that pixel-based sizing is deprecated (like what you're asking to keep) per Wikipedia:MOS:IMGSIZE. If layouts wherever are "correct" (for yourself, for example) using pixel-sizing, they're certainly broken for others, so the images were not correctly sized in the including page via the Wiki syntax. IIUC, it's best to solve as the above guidelines mandate. TSamuel (talk) 23:22, 27 March 2022 (UTC)[reply]
The file is used as it has been for some years on thousands of pages, so don't say it's "broken for some users"; that's just nonsense. Besides: are you going to fix all those pages? I don't think so, you'll probably wait until someone like me does it.
Question: why did you change these lines?
old:
<path stroke="#00F" d="m1.5,1.5h6v6h-6zh3v6m3-3h-6"/>
<path stroke="#EEE" d="m1.5,4V1.5h2.5"/>
new:
<path stroke="#00F" d="M1.5 1.5h6v6h-6zh3v6m3-3h-6"/>
<path stroke="#EEE" d="M1.5 4V1.5H4"/>
  • Why did you change "m" to "M"?
  • Why did you replace the comma with a space after M1.5?
  • Why didn't you add a space after all commands and values?
  • Why did you change "h2.5" to "H-4"?
Useless, inconsistent... :-( PS.: Please use the usual indentation to keep talk pages readable. - Erik Baas (talk) 23:46, 27 March 2022 (UTC)[reply]
You seem confused by absolute/relative SVG position syntax & optimization techniques. Please stop complaining if you won't even do the most basic search re: that. Your irrelevant OCD has nothing to do with this topic, which actually is properly indented (you could've looked!) but there's yet another bug in discussion display. I'll leave your precious file alone. It's enough for my version to be in the file history for potential future use. TSamuel (talk) 03:58, 28 March 2022 (UTC)[reply]
  • Not a single question answered: fail.
  • Confused by the syntax? Personal attack on my knowledge of SVG: fail. Hint: Category:Files by User:Erik Baas/BSicons.
  • Is this what you call "properly indented"? Fail.
<svg xmlns="http://www.w3.org/2000/svg" fill="#FFF" viewBox="0 0 9 9"><path stroke="#00F" d="M1.5 1.5h6v6h-6zh3v6m3-3h-6"/><path stroke="#EEE" d="M1.5 4V1.5H4"/></svg>
Again: please stop your useless and disrupting "optimization techniques"! - Erik Baas (talk) 09:19, 28 March 2022 (UTC)[reply]
I don't think referring to w:MOS:IMGSIZE really works here, because File:75_percent.svg is not an w:MOS:IMAGE (image used in articles for illustrative purposes), it is only used as w:MOS:ICON (small, decorative image) and it does not really work with the relative scale factor because it is so small. It really needs the pixel-perfect raster rendering when used on web, or it gets messy. Curious Walrus (talk) 09:49, 1 April 2022 (UTC)[reply]

On nl.wikibooks.nl is a list of 343 pages that still show your (too big) version of this file. Can you please fix that ASAP? Thank you. - Erik Baas (talk) 13:12, 6 April 2022 (UTC)[reply]

It seems to me that you have the most current (reverted) version of the file. If it's broken on all those pages, by your logic above, you should fix it, though I can't imagine what you'd do, since you reject my statement that those pages must actually be written incorrectly. My responsibility seems to end wherever my edits are no longer in place. 🙇🏾‍♂️ TSamuel (talk) 03:03, 7 April 2022 (UTC)[reply]
You should clean up your mess! Can be done by purging each and every one of those pages. Good luck. - Erik Baas (talk) 08:45, 7 April 2022 (UTC)[reply]

File:Inosine chemical structure.jpg[edit]

File:Inosine chemical structure.jpg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Afrikaans ∙ Bahasa Indonesia ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 中文 ∙ 中文（简体）‎ ∙ 中文（繁體）‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

Nucleus hydro elemon (talk) 12:02, 26 April 2022 (UTC)[reply]

TSamuel, it seems rather rich of you to claim that the file is "Low quality" when it was you who uploaded a lower-quality version. JPEG is a lossy format, so unless your recompression is lossless (though I can't see how it can reduce the size so drastically and be lossless), you contributed to lowering its quality. ‪JoKalliauer‬, Erik Baas, Alhadis and others have warned you about unnecessary recompression. If you keep repeating this, don't be surprised to find your account blocked.
As there is a PNG version, instead of nominating the JPEG for deletion, please instead add a template:superseded tag as I have done.
Thanks, cmɢʟee ⋅τaʟκ 18:34, 26 April 2022 (UTC)[reply]
I think you're confused. I don't have anything to do with said nomination. Such was done by the author of the superseding PNG. TSamuel (talk) 01:46, 27 April 2022 (UTC)[reply]
My apologies. I was mistaken and take back what I wrote. Sorry about that. cmɢʟee ⋅τaʟκ 16:10, 27 April 2022 (UTC)[reply]

File:Flag of India.svg[edit]

File:Flag of India.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Afrikaans ∙ Bahasa Indonesia ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 中文 ∙ 中文（简体）‎ ∙ 中文（繁體）‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

Editor8220 (talk) 13:20, 15 October 2022 (UTC)[reply]

"compressing" svg-files[edit]

hi, please stop "compressing" svg-files - stop creating oneliner and deleting structure of the code - you are invited to dive deeper in coding svgs - i am a greenhorn compared to @Sarang, Cmglee, Glrx, Perhelion, and JoKalliauer: - i am sure they will support you, i will too if i am skilled enough - svgomg and others are useful tools, but its not necessary to use them for editing in a large number of files - if that, this job would be done from bots or at least with help from semi-automatic scripts in commons-universe

doesn’t make you think that several people ask you to reconsider this kind of edits? --Mrmw (talk) 19:25, 24 February 2023 (UTC)[reply]

@TSamuel: Please read Help:SVG_guidelines
I explained on the example of File:Venn0111.svg what you did wrong:
or at File:Reinel_compass_rose.svg there is no relevant file-size reduction, and both files are from the last 10 svg-files you uploaded


Which of the two versions is better readable:
<svg xmlns="http://www.w3.org/2000/svg" stroke="#000" viewBox="0 0 409.71 298.52"><path fill="#fff" stroke-width="5.05" d="M2.53 2.53h379.03v274.79H2.53z"/><g fill="red"><g transform="matrix(.8426 0 0 .8407 -10.24 -10.52)" stroke-width="6"><circle cx="180" cy="180" r="120"/><circle cx="300" cy="180" r="120"/></g><path d="M191.97 53.44c31.28 18.02 50.55 51.33 50.55 87.37s-19.27 69.35-50.55 87.37c-31.28-18.02-50.55-51.33-50.55-87.37s19.27-69.35 50.55-87.37" stroke-width="5.05"/></g></svg>
or
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" height="280" width="380" stroke="#000" stroke-width="5">
 <rect x="2.5" y="2.5" width="375" height="275" fill="#fff"/>
 <circle cx="140" cy="140" r="100" fill="#f00"/>
 <circle cx="240" cy="140" r="100" fill="#f00"/>
 <circle cx="140" cy="140" r="100" fill="none"/>
</svg>
The second one has xml-highlighting since it has an xml-declaration and the first one hasn't
 — Johannes Kalliauer - Talk | Contributions 21:54, 24 February 2023 (UTC)[reply]
I'm generally retired from any SVG-editing work since the latest round of rules have been enshrined. If any of my work offends anyone, please feel free to revert. 🙇🏾‍♂️ TSamuel (talk) 11:40, 26 February 2023 (UTC)[reply]

Stop immediately[edit]

your senseless and contraproductive "compressing" which is mainly removing linefeeds and so destroying source code readability.

Real SVG code reduction can anly be done with thoughtful new-drawing, and never with a tool that removes just linefeeds ! See as an example Piccadilly line roundel (no text).svg -- sarang♥사랑 06:08, 21 May 2023 (UTC)[reply]

Nowadays, I'm just touching those ignored Simplified SVGs that clearly are not, just to get them on the radar of someone like you who's gifted & more aware of the Wiki*edia rules. Thanks for what you do. 🙇🏾‍♂️ TSamuel (talk) 11:29, 21 May 2023 (UTC)[reply]
Category:SVG_simplified_logos is a subcategory of Category:SVG_Simplified, which is for "manually drawn SVG graphics", however your simplifications seem to use (semi-)automatic tools instead of manually drawings, and therefore files after your "optimization" should be removed from Category:SVG_Simplified and it's subcategories.
According to Help:SVG_guidelines#When_is_optimizing/validating_files_undesired?, you should not remove linebreaks.
I looked at some of your files:
Last week the wiki-renderer was updated, why many renderings will change, see Librsvg_bugs and phab:T193352.
We really need your help: Could you help us checking the images in Category:Pictures_showing_a_librsvg_bug:
  1. Some of them are rendered now correctly they should be moved into Category:Pictures_formerly_showing_a_librsvg_bug
  2. Some of them are still rendered wrong, they should be (i) reported at phab:tag/wikimedia-svg-rendering and (ii) if you could provide a workaround (e.g. with SVGO) that would be perfect.
 — Johannes Kalliauer - Talk | Contributions 02:37, 22 May 2023 (UTC)[reply]

Controversial or contested changes[edit]

Many of your changes involve compressing SVG code into a single line. (e.g. File:Askvoll komm.svg and File:Flag of the Chechen Republic.svg) It is obvious on this talk page, that other users mainly see this as annoying and pointless. (Is there actually anyone who thinks source code should be in one line?) This unwelcome detail clearly makes these changes controversial and contested, which means that they are against the rules for overwriting images. Please stop doing this, or probably you will be stopped. Watchduck (quack) 22:28, 8 August 2023 (UTC)[reply]

What skill do you need to ru such a business@ 41.114.42.19 17:58, 17 August 2023 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=User_talk:TSamuel&oldid=793967585"