User talk:Glrx/Archive 13

Precious anniversary
--Gerda Arendt (talk) 07:21, 25 May 2021 (UTC)

Speedy deletion nomination of File:Network Time Foundation IRS Form 990 2012.pdf


A tag has been placed on File:Network Time Foundation IRS Form 990 2012.pdf requesting that it be speedily deleted from Wikipedia. This has been done under section F10 of the criteria for speedy deletion, because it is a file that is not an image, sound file or video clip (e.g. a Microsoft Word document or PDF file) that has no encyclopedic use.

If you think this page should not be deleted for this reason, you may contest the nomination by visiting the page and clicking the button labelled "Contest this speedy deletion". This will give you the opportunity to explain why you believe the page should not be deleted. However, be aware that once a page is tagged for speedy deletion, it may be deleted without delay. Please do not remove the speedy deletion tag from the page yourself, but do not hesitate to add information in line with Wikipedia's policies and guidelines. Hog Farm Talk 15:50, 21 August 2021 (UTC)

Nakajima Ki-201
Noticed you removed everything Justin claimed was factually wrong, but here is the question: what makes Justin such a superior source that the other sources can be dismissed? BP OMowe (talk) 04:50, 17 February 2022 (UTC)
 * Those edits were a long time ago. I trust Drachinifel, and, IIRC, he reasonably pointed out errors in the WP article. See https://www.youtube.com/watch?v=r1sn-1ZCmDg at 54:05. Some text I deleted was not sourced, but I also left in some unsourced material. Anybody here can edit the article. Glrx (talk) 05:10, 17 February 2022 (UTC)


 * That were claims and statements by Drachinifel's guest "Justin", as Drachinifel clearly stated that he himself has no expertise in aviation.

Justin simply crossed out large portions stating they are factually wrong. Since there are sources given, was the text not in accordance to those sources, and that being the reason Justin rejected the text, or did he consider the sources themselves erroneous on the topic? Anyway, that's just ponderings of mine, my main question was if you know who Justin is, and what authority he has in the field :) BP OMowe (talk) 13:19, 26 February 2022 (UTC)

Precious anniversary
--Gerda Arendt (talk) 07:26, 25 May 2022 (UTC)

ArbCom 2022 Elections voter message
 Hello! Voting in the 2022 Arbitration Committee elections is now open until 23:59 (UTC) on. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2022 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add to your user talk page. MediaWiki message delivery (talk) 00:36, 29 November 2022 (UTC)

Precious anniversary
--Gerda Arendt (talk) 08:02, 25 May 2023 (UTC)

Broken Time-to-digital converter link
Eleven years ago you linked to a navy.mil PDF in the Time-to-digital converter article:

https://en.wikipedia.org/w/index.php?title=Time-to-digital_converter&diff=prev&oldid=482781943

However, now the link is dead and sinc it was inserted without any meta information I have no clue what publication that might have been.

Do you remember? Do you have an alternative link? Gms (talk) 14:50, 27 September 2023 (UTC)


 * Dig the link out from archive.org. Glrx (talk) 18:01, 28 September 2023 (UTC)

ArbCom 2023 Elections voter message
 Hello! Voting in the 2023 Arbitration Committee elections is now open until 23:59 (UTC) on. All eligible users are allowed to vote. Users with alternate accounts may only vote once.

The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to impose binding solutions to disputes between editors, primarily for serious conduct disputes the community has been unable to resolve. This includes the authority to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail.

If you wish to participate in the 2023 election, please review the candidates and submit your choices on the voting page. If you no longer wish to receive these messages, you may add to your user talk page. MediaWiki message delivery (talk) 00:30, 28 November 2023 (UTC)

SVG problems
Please see: [https://phabricator.wikimedia.org/T64986 T64986. librsvg does not support fallback font set (more than one font family)].

I am curious to know how all this underlying Mediawiki SVG software is maintained? Like librsvg and so on.

And why Mediawiki keeps using an old version. Is it a matter of not enough Wikimedia staff to stay on top of it? Is it a matter of money needed to keep the software updated?

Are grants needed? People? Coordination? Both in Wikimedia and outside? --Timeshifter (talk) 19:33, 1 December 2023 (UTC)


 * I have no idea how MediaWiki software is managed.
 * T64986 is a regression error. It was fixed once, but now the error has reemerged.
 * T64986 can be fixed by updating  in the current operating system. WMF has not done that. The installation may trigger problems with other systems: https://itsfoss.com/apt-install-specific-version/ says Ubuntu does not like to keep multiple versions around.
 * T64986 can be fixed by upgrading the operating system. The current Thumbor operating system is about 4 years old. WMF seems to prefer this approach, but I do not know the timeframe.
 * Glrx (talk) 20:14, 1 December 2023 (UTC)
 * Wow. Thanks. I looked at a few tasks and the many interconnections. Lots of work.
 * I am wondering though. Is there a simple way to plug in a different standard fallback font? The fallback font that is used when no useful font has been found in the SVG code of an image. See my last comment in T64986. Could a narrower font be used?
 * See also: SVG file upload: Allow to preview SVG file without external URLs loaded and continue upload after removal of external "@import url". People need to be able to preview the SVG file after the font substitution occurs to see if it looks right.
 * --Timeshifter (talk) 22:18, 1 December 2023 (UTC)
 * The simple approach just use CSS generic fonts: serif or sans-serif. Leave plenty of room for the text.
 * I'm opposed to using a narrow font. It would solve one of your problems, but it could make other illustrations look odd. Overruns look bad, but underruns can also look bad.
 * I'm also opposed to removing @import. If an SVG file needs an import to display properly, then removing the import will break the file (e.g., Siddham script will not display). If an SVG file does not need an import to display properly, then it should not have the import in the first place. Too many applications try to be clever by half. Web fonts are a nice idea, but they also enable tracking.
 * Many of WMF's SVG preview apps are broken right now.
 * My experience has been when people use their favorite exotic font, tweak the spacing so the text just fits, and then display it on another system (not just a WMF wiki), the result is poor. It can even be the SVG on their system looks bad at some sizes; fonts do not scale linearly. Sometimes users get so frustrated that they convert the text to curves; that is not a good result. Users who employ generic fonts, avoid complex font options such as narrow or light fonts, leave plenty of space for variations in font metrics (say 10 pecent), and choose appropriate text anchors get reasonable results. Such files are also better candidates for translation.
 * Glrx (talk) 22:59, 1 December 2023 (UTC)

Oops. I fixed the link: SVG file upload: Allow to preview SVG file without external URLs loaded and continue upload after removal of external "@import url".

I discovered that for SVG images with links embedded in the image, Mediawiki doesn't remove the URLs. It just disables them. See: When you download the image from the Commons, and then open it, you will see that the top and bottom lines are linked. So MediaWiki is just disabling them.
 * File:Population density map of the world.svg

I had to remove the @import to get it to upload. See T351978. Mediawiki could disable (not remove) that URL too.

Maybe after the preview during the upload process Mediawiki could offer a choice between a narrow, normal, and wide font. And then further previews. Mediawiki already shows images of similarly named images, or duplicates, when uploading. Why not previews?

SVG creators outside Wikimedia create images with font families. Most people have no problem seeing them since the font families usually contain something for Windows, Macs, Linux, etc.. And finally a generic CSS font: serif or sans-serif. I think it is a little too much to expect SVG creators to go backwards and only say serif or sans-serif.

I think it is up to Mediawiki to change, not the outside SVG creators. They are usually not even creating their images with Mediawiki in mind.

OWID files don't absolutely "need" the @import font. OWID SVG files have font family lists too. I think the import is just for some special fonts they prefer. But they are not essential. One of the other fonts in the font family list will work. I know this is true because I can still open the SVG file after I remove @import. In fact all my browsers on my Windows 10 Pro PC can open the file with or without the @import file. It is only Mediawiki that is having a problem. --Timeshifter (talk) 00:19, 2 December 2023 (UTC)


 * MediaWiki does not block links. MediaWiki converts SVG files to PNG files when it displays them on a wiki page. PNG files do not process links. MediaWiki puts users two clicks away from a potentially malicious sites.
 * MediaWiki blocks SVGs with @import by design. It prevents malicious behavior and tracking.
 * MediaWiki is not in the business of tweaking images. That's for graphics apps.
 * Font family fallbacks are a good idea, and WMF used to support them. That's the Phab issue. But even that is not a complete solution. Adobe tools use Adobe font naming conventions, and that makes it difficult to do sensible font substitutions.
 * If a creator wants its SVG to be viewable on many platforms (which is a goal of WMF), then the creator should not be using exotic fonts or exotic CSS.
 * Glrx (talk) 01:44, 2 December 2023 (UTC)
 * You are right. Mediawiki doesn't have to do anything to disable a link other than convert the image to PNG.
 * I have no problem with Mediawiki blocking @import by design. I just wish Mediawiki would not block uploads with @import. I have a question. How is @import dangerous if the SVG is converted to a PNG file?
 * Maybe Mediawiki is worried about passing on an SVG file with @import when people download the SVG file. I can understand that. So I am back to why Mediawiki just doesn't remove it, and show a preview. These are free images. We are allowed to make derivatives.
 * "MediaWiki is not in the business of tweaking images." It's our software. We can do whatever we want if people agree to it.
 * "exotic fonts or exotic CSS." As I said already OWID has a font family list in its SVG files. OWID files are viewable on many platforms without the imported fonts. Even with the imported fonts I don't believe OWID is doing malicious behavior and tracking.
 * And the problem is solved by removing @import. --Timeshifter (talk) 05:53, 2 December 2023 (UTC)
 * --Timeshifter (talk) 05:53, 2 December 2023 (UTC)
 * Imports are dangerous. Users who download the file may be tracked. Also MediaWiki may start sendingg SVGs directly to the client's browser. One of the reasons for PNG conversion was poor SVG support a long time ago. That has changed. A continuing reason for PNG conversion is some SVG files are huge.
 * It is much better if a software charter is limited. Yes, it might be nice if X did Y, but soon you're adding the kitchen sink. Keep it simple. WMF does not allow imports, scripts, most DTD subsets, and only a couple dozen namespaces.
 * Maybe OWID is not trying to track, but it is impossible to tell for every possible @import. Google has a wonderful set of fonts, but if someone uses them as WebFonts, then Google will be pinged often. Googles business is tracking.
 * It is not that simple. Simply removing @import may break the file. Removal may solve your current problem but it creates others.
 * Glrx (talk) 20:46, 2 December 2023 (UTC)
 * As I said, remove @import, then preview it for the uploader, then let the uploader decide whether to continue the upload. Problem solved. Wikimedia gains access to tens of thousands more quality SVG files. It's a no-brainer to me. --Timeshifter (talk) 22:51, 2 December 2023 (UTC)

need your help
redraw File:Kategorien der Existenz bei Whitehead.svg - i am fine with it, but get crazy of the double-arrow at the very button - i am not able do form a correct double-arrow form with arrow to the left and with arrow to the right - in inkscpae its rendering correct - thx --Mrmw (talk) 18:12, 11 December 2023 (UTC)
 * The current SVG is
 * The issue is . The keyword   means orient the marker in the current direction of the drawn path segment. You want , but that is an SVG 2.0 feature that is not supported by WMF right now (works in Chromium). To make it work in SVG 1.1, you need to make another marker:
 * Glrx (talk) 22:01, 11 December 2023 (UTC)
 * thx, i use uptodate chrome-browser - and its not working, therefore i changed auto-start-reverse to auto - inkscape also uses auto-start-reverse as default
 * also tested edge - its also not working
 * also firefox with latest version shows incorrect arrows
 * which browser do you use? --Mrmw (talk) 06:21, 12 December 2023 (UTC)
 * Chrome and Edge are built from Chromium; both show the left and right arrowheads for me. My Firefox also shows left and right arrowheads.
 * https://upload.wikimedia.org/wikipedia/commons/a/ab/Kategorien_der_Existenz_bei_Whitehead.svg
 * Google Chrome Version 120.0.6099.71 (Official Build) (64-bit)
 * Microsoft Edge Version 120.0.2210.61 (Official build) (64-bit)
 * Mozilla Firefox 120.0.1 (64-bit)
 * The operating system is Windows 11.
 * Yesterday, when I was testing, the preview from SVG Edit was correct, but I had to clear the browser cache to see the updated SVG.
 * Glrx (talk) 18:23, 12 December 2023 (UTC)
 * thx for your support, but i am still confused
 * are you sure your version of the file with marker works correct? for me it seems preview at bowser-svg-editing shows another result as file is part of an article, for example: de:Benutzer Diskussion:Mrmw/test
 * does this image on my user-page show all arrows correct?
 * thx --Mrmw (talk) 18:52, 12 December 2023 (UTC)
 * The article shows an incorrect image. The SVG 1.1  paints it incorrectly. I must show the SVG in my browser to see the correct arrows.
 * If you want  to display the image correctly, then   must point to another marker with a reversed image.
 * If you go to Commons:File:Kategorien der Existenz bei Whitehead.svg, click Rillke's SVG Edit, and then click Rillke's Preview, you should see the angry bug (failed  rendering) and the browser's rendering (with correct arrows).
 * Glrx (talk) 19:30, 12 December 2023 (UTC)
 * The article shows an incorrect image. The SVG 1.1  paints it incorrectly. I must show the SVG in my browser to see the correct arrows.
 * If you want  to display the image correctly, then   must point to another marker with a reversed image.
 * If you go to Commons:File:Kategorien der Existenz bei Whitehead.svg, click Rillke's SVG Edit, and then click Rillke's Preview, you should see the angry bug (failed  rendering) and the browser's rendering (with correct arrows).
 * Glrx (talk) 19:30, 12 December 2023 (UTC)
 * Glrx (talk) 19:30, 12 December 2023 (UTC)