Talk:BSicon/Icon geometry and SVG code neatness/Archive 3

Limited service halt

removed from User talk:Useddenim

re:  (pHST), I think it would do better as "XHST" or outright replacing  (xpHST) (it's a better design IMO). As is the name conflict with the x- prefix... Circeus (talk) 13:16, 26 September 2011 (UTC)

The p prefix seemed to be a natural for "partial" (better than xp for "express"), so I just threw them in there. However, I don't know what others would think of a substitution, though. Useddenim (talk) 13:46, 26 September 2011 (UTC)

---

I'm wondering which of the following should be used for a limited service halt:  (pHST) or  (xpHST). I see xp = express not stopping and p = limited service however  (pBHF) or  (xpBHF) are identical.

Deonyi (talk) 11:44, 13 April 2013 (UTC)

The p- version was actually created, if I remember correctly, as an alternative, more visible version to the xp- design for HST. I've used it in one instance where the station is not "limited service" (admittedly I'm not sure what that is defined as) but in fact used only on certain special occasions. I'm not sure the distinction would work very well if applied to "full-sized" stations. Can you think aof an actual use case? Circeus (talk) 03:13, 14 April 2013 (UTC)

Well, in Melbourne the flemingtom line is for race and showground days only yet theyre staffed when open. Maybe we need a new icon; Dst with a dot in the middle showing limited service.

Deonyi 13:38, 14 April 2013 (UTC)

Which is exactly how I've used  (pHST) for en:Showground Central railway station. I'm duvious this usage case can have a HST/BHF distinction, since such stations are bu definition hardly ever BHF material. Circeus (talk) 19:10, 14 April 2013 (UTC)

I'm talking about the Melbourne one, en:Showgrounds_railway_station,_Melbourne. That's a fairly large station and if being used they always stop there therefore being a 'main station'. It's manned whilst being used so I'd say it is a special use station. Deonyi (talk) 11:22, 15 April 2013 (UTC)

If you feel that strongly about it, just overlay a DST icon with the pHST:    I, for one, don't think that it's necessary to create a single specialized icon for one user for one station on one diagram. Useddenim (talk) 11:19, 16 April 2013 (UTC)

Okay, case in point here now. We’re addressing two different matters here. They need to be dealt with separately and not conflated, or else we risk needlessly foil a satisfactory outcome.

1. The original prefix "xp" (from "express") was used in BHFs and HSTs to mark an optional halt. It was later reanalized to mean "x"+"p", the former being the same as in  (xBHF) vs. plain  (BHF), thus yielding a rump  (pBHF) to mean the same as the original semantics. The transition was made smooth by the fact that there’s almost no need for x-stations (open station on closed line — only makes sense in diagrams where the general samantics of the icons is adapted to a particular need). After the icons of the f- and u-series were created and moved, now finally come the time to have it implemented.
2. It was argued that the geometry of the icon (a station disc broken by a line over it with visible gaps) is unsuitable for the much smaller HSTs, making it hard to interpret, e.g.,   (“pHST”) vs.  (“epHST”); the alternative design of a disc with a white ring inside was therefore uploaded as  (pHST) and other thusly modified icons followed suite. While I don’t disagree with the basic premise, I think that such a big difference should be better embodied by uploading a parallel series of icons, with a differing root name or a "!" in their filenames, pending discussion. This is even worse when it happens while there is a massive and slow cascading renaming process going on.

I suggest that these two topics be discussed in separate, and for there I added two separate subheadings below. -- Tuválkin ✉ 19:24, 28 May 2014 (UTC)

xp becomes p

Seems that this matter is now all decided for, right? -- Tuválkin ✉ 19:24, 28 May 2014 (UTC)

Design of pHST

BHF pBHF pHST(!!) HST

How about this one:  (pHST(!!)) ? Seems to go well with  (pBHF). YLSS (talk) 22:02, 28 May 2014 (UTC)

I like it. (It is better than my idea of having full hemispheres attached to either side of the gap, as in  …) The operation idea here is to have the same design for both HST and BHF — if not geometrically identical, at least visually similar and conceptually equivalent. -- Tuválkin ✉ 23:45, 28 May 2014 (UTC)

I like  (pHST(!!)) better than  (pHST) (and pHST was my design!). Useddenim (talk) 00:46, 29 May 2014 (UTC)

In use now at en:Template:New Jalpaiguri–Haldibari–Parbatipur line — looks good! -- Tuválkin ✉ 09:13, 9 June 2014 (UTC)

New shape for optional stops

Is it a matter of shape only, or a different semantics is implied for   vs. …? -- Tuválkin ✉ 19:24, 28 May 2014 (UTC)

I certainly prefer a design similar to  (pBHF). So I would ditch the current  (pHST)... But possibly it would do better in the context of Limited Service Lines (the ones introduced here)? It would be interesting to know what Deonyi thinks. YLSS (talk) 22:08, 28 May 2014 (UTC)

I thought the second one was the more 'visible' version. Some more clarification would be nice.User:Deonyi 09:24, 29 May 2014 (UTC)

---

I have re-uploaded some icons and made a request to sort out the histories, preserving as much older versions as possible. Let's hope some admin will do that task. ^{Done by Ankry, thanks again} I hope you guys do not mind that I nominated some of your uploads for deletion... I suggest that any more re-uploads are preformed only after all this is done. ^{Re-uploaded all} Following that, we'll be left with replacing current usages of  (xpHST) to  (pHST),^{This one apparently will take a long while} then moving  (epHST) to xpHST, and then moving xpHST(!) to epHST. ^{Not done I didn't intend it this way, but I also messed the things up on my PC and uploaded the files the other way round. Well, let it be like that. xpHST(!) should still be de-exclamationized one day. 16:25, 14 June 2014 (UTC)} Do your heads start spinning round? ;) YLSS (talk) 08:45, 14 June 2014 (UTC)

I moved some of the use of xpHST to  (pHST), but there’s still a long way to go. -- Tuválkin ✉ 13:03, 16 June 2014 (UTC)

 Done with this one. However, there's also  (xpBHF). YLSS (talk) 22:34, 27 June 2014 (UTC)

Lines in tunnel

Ideally, the background should show through everywhere on an icon, except where the line actually is; as shown by the green example:

<path d="M 45,-25 V 575 M 105,-25 V 575" 
   stroke="#color" stroke-width="40" stroke-dasharray="50" fill="none" />

However, this is not always possible (particularly with curved paths), and oftentimes editors have resorted to a 100px dashed line overlaid by a 20px solid line, illustrated in red. (Note that the default background colour for BS icon route diagrams is  f9f9f9  , not  white  .)

A better result can be obtained if the masking is contained within the track line, depicted here in blue:

<g stroke-width="100" stroke-dasharray="50" fill="none">
   <path d="M 250,-25 V 575" stroke="#colour" />
   <path d="M 250,-25 V 575" stroke="#f9f9f9" stroke-width="20" />
</g>

where the group element defines the overall colour and dash array, and the mask contains its own specific overrides.

Hopefully this is helpful and of interest. Useddenim (talk) 01:13, 28 December 2011 (UTC)

Yes, it is. -- Tuválkin ✉ 02:09, 30 December 2011 (UTC)

Design of the gapped lines at icon edges

I think I understood that the ideal design of these tunnel icons is to have the 50px blocks cut in half (25px on each side) when lines cross icon edges at 90°, is that right? Meaning all icons showing otherwise are unperfectly design and should be fixed sooner or later? -- Tuválkin ✉ 03:01, 15 January 2013 (UTC)

This point illustrated on this mock diagram →, with pink one being correct and the blue one needing a fix in the curve in order to look smooth. (Of course the center of the pink icons needs to be worked on to match, maybe changing 50 to slight more, or less.) -- Tuválkin ✉ 04:42, 15 January 2013 (UTC)

Yep, stroke-dasharray="46.875" does the trick. Will fix. -- Tuválkin ✉ 04:54, 15 January 2013 (UTC)

Even better, stroke-dasharray="53.125" unclutters the middle of the crossing (i.e. the icon edge where the line meets not orthogonally) and is exactly the same deviation from 50 as above. Will fix now. -- Tuválkin ✉ 05:21, 15 January 2013 (UTC)

Basing on this, I overwrote (and expanded) all simple KRW-junctions, e.g.  (xtKRWgr). I used stroke-dasharray="50,56.75", because it is easier to have all strokes 50px long, and to variegate the length of gaps. It is really quite fortunate that in contrast to ÜW-junctions, here we can have perfect crossings and perfect shifts at the same time. YLSS (talk) 23:50, 30 October 2013 (UTC)

For the record: krws in tunnel were mostly finished up by Sameboat in January 2014. Only icons with bridges remain, like  (extKRWl+lo). YLSS (talk) 16:23, 11 July 2014 (UTC)

Curves in tunnel

Btw, there is a section above #Lines in tunnel for the similar matter, but I hope a new section would be more helpful.

Since the number of 45° icons have been growing fast, and I notice there are more tunnel versions of them emerging, I think I should take a chance to document what I have learnt from creating curved tunnel icons.

First, it is actually possible to not add the little white segments between dashes. This effect was actually done by masking in SVG to not to render the middle strip of curve. Check out the code of  (tSTR2) if you are interested. However, since the wiki renderer is not perfect about the syntax of masking, I had been trying for a few times to make things right.

Second, unfortunately there are no standard way to dash the track so far. This is further complicated by the fact that the curves are unlikely to have lengths of multiple of 50, which works perfectly for straight tunnels. For example, the ÜW curve of  (tSTR2) "M250,0 C250,250 375,375 500,500" has a length of approximately 577.75719 from edge to corner. The diagonal line of  (tSTR2+4) has a length of approximately 707.10678. When I first created tunnel versions for ÜW, I simply used 577.75719/12 = 48.146 for its dasharray, and, later when the diagonal track appeared, spent some hard time to figure out what kind of dashes would look natural. Yet, for icons from other authors, they could have some other geometries that would not fit nicely. My advice for new authors is to find out the actual numerical length of the Bézier curves or circular arcs, and decide what dasharray and dashoffset would be suitable.

Anyway, I could just be too picky on the dashes, and I don't think there are urgent needs to convert all the existing ones to a standard. I only want to share my experience when I made those tunnel ÜW icons and hope the future ones would fit better. Peterwhy (talk) 18:50, 10 March 2013 (UTC)

tÜW intersect at coloured dash extÜW intersect at transparent dash utÜW intersect at coloured dash (compare with tKRZt) (and utKRZt) uextvÜW with 20px gap extvÜW with 50px gap utABZ23 vs. utABZg23

Peter, thanks for this. I will surely be coming back to this section over and over whenever I need to (re)create a tunnel icon and need an accurately drawn model.

One question: Which do you consider better —  (extSTR2) or  (utSTR2)? While the stub end is good (half a dash), the corner end of these two is different (slight difference in dasharray), resulting in different central “keystones” where they meert. It is important that this is identical for all icons for smooth matching. -- Tuválkin ✉ 01:29, 12 March 2013 (UTC)

IMHO,  (extSTR2). Useddenim (talk) 14:52, 12 March 2013 (UTC)

Same,  (extSTR2), but only without the corner piece overlaid. The right ones are with overlay corners. Peterwhy (talk) 16:17, 13 March 2013 (UTC)

I've redrawn  (utKRZt) with "perfect" corners at the crossing, for comparison. Useddenim (talk) 13:29, 14 March 2013 (UTC)

Here I actually think  (tKRZt) one is better, and a simpler code means easier to code and more consistency (hopefully). Peterwhy (talk) 14:22, 14 March 2013 (UTC)

Peterwhy, you're a genius! x="-100" y="-100" width="1200" height="1200" is a good workaround for librsvg bug that frustrated me so much! And also a note for those who would wish to use masking: make sure that mask="url(#smth)" stands in another element (possibly at an outer level) from any stroke-dasharray's & stroke-dashoffset's. In  (uetABZgr+r) I used both masking and Redrose64's suggestions below. YLSS (talk) 19:36, 13 October 2013 (UTC)

Basing upon the discussion above, I decided to experiment and now present you with two options. The "uex" curves to the right intersect at a tight spot with 20px between the coloured strokes (just like in Useddenim's "ex" version above). When this is used only for a shift, without intersection, this doesn't look as good, and this is perceptible even at 20px size. Below are new "ex" versions, in which the gap at corner is the standard 50px and the "shift" is perfect; in case of intersection, the result is the same as  (tKRZt) rotated by 45°. (In this case the "extÜWc#" degenerate into two tiny triangles, less than a pixel in size at 20px scale and possibly omittable.) I prefer the second option slightly more than the first; what do others think? YLSS (talk) 21:47, 19 October 2013 (UTC)

Anybody? I'm dying to re-upload them with a common design! YLSS (talk) 21:33, 22 October 2013 (UTC)

Personally, I prefer the “perfect” corners of uextvÜW with 20px gap, but since the 50px gap is the accepted design for the 90°  (tKRZt) crossings we should probably use extvÜW. Useddenim (talk) 00:13, 23 October 2013 (UTC)

Well, let's then consider this matter settled: tSTR#s should have their last stroke terminating at 25px before the corner, measured diagonally, while tÜWc#s should look like two tiny ears . YLSS (talk) 23:51, 7 November 2013 (UTC)

Next issue. In  (utABZ23) I used stroke-dasharray="50,55.7" to achieve the result described above, and everything looks fine. When I added a vertical track in  (utABZg23), the over-shifted strokes of the curves came into dissonance with the strokes of  (utSTR), and the result didn't look fine. In order to compensate this, I used stroke-dasharray="50,50,50,50,50,50,50,59,55,59.4,55", so that the first four strokes are 50px long with 50px gaps, and afterwards - when the curve deviates enough from the vertical - the gaps are 59px long, and the strokes are 55px long. IMHO, this looks better; check pt:Linha Azul (Metropolitano de Lisboa). However, this bring another question: Tuválkin, AFAIK, is a proponent of the idea that an icon should look exactly the same as the result of overlaying its parts, but in this case the strokes won't overlap. Is that OK? In the end, this is the ultimate purpose of creating complex icons rather that satisfying one's self with |O1= ... |O15= .... YLSS (talk) 23:51, 7 November 2013 (UTC)

---

 Done with uextÜW series (except for some icons with portals which still puzzle me). YLSS (talk) 11:32, 4 May 2014 (UTC)

 Ditto with utÜW series. YLSS (talk) 14:21, 10 July 2014 (UTC)

 Done with extÜW, tÜW and "other colors". The only thing that remains is icons with portals and/or bridges, pending the discussion at Talk:BSicon/Icon geometry and SVG code neatness/Formations. YLSS (talk) 16:16, 22 July 2014 (UTC)

uextSTR14lr

was uextSTR14lra → was uextSTR14lr ↓		was uextSTR14lrl ↓

I guess these three were intended to work together, but remain unused. The middle one has full rights to live, but at 20px there is no perceptible difference between   (uextSTR14lrr) vs.  (uextÜWc1) and   (uextSTR14lrl) vs.  (uextÜWc4). Deletion candidates? YLSS (talk) 20:02, 9 April 2013 (UTC) (Added uextSTR14lra. If the central one is redrawn, this one can be salvaged as  (uextÜWc23). YLSS (talk) 21:17, 9 April 2013 (UTC))

 Support. And   (uextSTR14lr) should probably be redrawn to use the standard geometry of   (uÜWu4) and   (uÜWu1). Useddenim (talk) 20:08, 9 April 2013 (UTC)

 Done Useddenim (talk) 01:20, 13 April 2013 (UTC)

 Done uextSTR14lra →  (uextÜWc23) as well. YLSS (talk) 10:13, 13 April 2013 (UTC)

File:BSicon uextSTR14lr.svg utSTR14lr

Check this example: → I think Useddenim drew the corners of   (uextSTR14lr) slightly incorrectly, not a perfect match as continuation of the curve past the portals, as intended. I created   (utSTR14lr) with the tunnel bits taken from  (utSTR3+1) and  (utSTR2+4) (minor incorrections as the the tunnel stretches are straight, not curved). The result is not a perfect match, though, because many tunnel icons were not drawn well enough to match, as discussed elsewhere. -- Tuválkin ✉ 19:27, 20 May 2013 (UTC)

Okay, I changed the tips of the tunnel track at the corners and made the portals round in   (utSTR14lr), and it is now reflected in the diagram at the right (clear cache!). Opinions? -- Tuválkin ✉ 14:48, 11 July 2014 (UTC)

WRT corners, top notch! WRT portals, moved everything here. YLSS (talk) 17:51, 11 July 2014 (UTC)

Tunnel geometry on 90-degree curves

For some time I've found the appearance of some of the tunnel icons (those like  (tSTR) etc.) unsatisfactory: there are inconsistencies in several characteristics, such as the mark length and the mark/space ratio (both controlled by the stroke-dasharray property), and the mark offset (the stroke-dashoffset property}. For example, on  (tABZql), the straight track has stroke-dasharray:48 and there is no stroke-dashoffset. This means that at one end, there is a full mark 48px long; at the other is a partial mark 20px long - less than half the size of a full mark. The four icons in red at right show some of these inconsistencies.

Many of the tunnel icons use stroke-dasharray:50;stroke-dashoffset:25 in the straight track which gives a half-size mark at each end flanking four whole marks - it's neat and symmetrical. With this in mind, I've calculated optimum measurements for icons like  (tSTRlf). Given that the cell width is nominally 500, and the quarter-circle is thus radius 250, it can be shown that the arc length is 392.699 - this is quite close to 400, so with five marks and five spaces along the straight track, a quarter-circle should have four marks and four spaces. The inner ring of dashes (radius 220) is stroke-dasharray:43.197;stroke-dashoffset:21.598; and the outer ring (radius 280) is stroke-dasharray:54.978;stroke-dashoffset:27.489; Using these measurements, I've redrawn  (extABZql) and created  (extABZqr)  (extABZq+l)  (extABZq+r) which didn't previously exist. The four icons in pink at right demonstrate the improvement. Opinions? --Redrose64 (talk; at English Wikipedia) 17:11, 12 October 2013 (UTC)

Great thanks, this has long bugged me! I can only add that one digit after the point would be more than enough ^{(OK, two for dasharray)} (43.2, 21.6, 54.98, 27.5 respectively); and that if it is desired to use #F9F9F9 masking for the central line, the numbers are stroke-dasharray:49.09;stroke-dashoffset:24.5 (392.699 / 4 ≈ 49.09, 49.09 / 2 ≈ 24.5), see the "uex" group to the right. BTW, do not test such things in Chrome, it is somewhat buggy; Mediawiki's librsvg, IE and Firefox seem to be OK. YLSS (talk) 19:50, 12 October 2013 (UTC)

One decimal place of decimal would give an error of 0.4 pixel on the complete circle, and two decimal places would give an error of 0.08 pixel, with the 3-o'clock mark being too small by that amount. By contrast, three decimal places would give an error of -0.012 pixel, so the 3-o'clock mark is a tiny bit too large. Either way, it's not much, but I like to get as close as possible without going to extremes: there's an infinite number of decimal places on the exact calculation, since the exact mark size would be 250*π/16 on a 250px circle.

Leaving that aside, I saw the post of YLSS 19:36, 13 October 2013 (UTC), and it's helped me with my original intent - I couldn't get the <mask> element to work, now I see that you need a big white rectangle to make everything opaque that is not masked. Accordingly, I've redrawn  (extABZql) again, using two paths instead of four, with masking to give a clear space down the middle of both paths even where the strokes overlap. There's a subtle change to the shape of the marks which make up the two circles, that makes them even neater. --Redrose64 (talk; at English Wikipedia) 14:12, 14 October 2013 (UTC)

Much better! (I've also been having a hard time making tABZ icons look good.) Useddenim (talk) 00:04, 15 October 2013 (UTC)

No complaints, so I've redrawn the other three pink icons so that there is a complete transparent circle in the middle group at right.

I did all of this in a plain text editor, checking the results in Firefox; after I finished, I loaded one of them into Inkscape - but with strange results. It recognises the fill="white" (opaque) part of the mask, but not the stroke="black" (transparent) part. --Redrose64 (talk; at English Wikipedia) 17:40, 17 October 2013 (UTC)

All this masking, though handy, requires a lot of double- and triple-checking. I have now encountered another bug (?) in that sometimes a mask renders invisible a large section of the object it is applied to, far more than intended, and this shows up in Chrome, Firefox and IE. The workaround is to add an additional e.g. M 500,0 at the beginning of d in the path element (see e.g.  (uextvSTR+1-)); this solves the issue everywhere except in Firefox. Possibly this isn't a bug, but some coordinate conversion? YLSS (talk) 18:18, 17 October 2013 (UTC)

A related question. I've been uploading icons with the following notion: when in junctions a normal track crosses an unused one, not only it is drawn "on top" of it, but also it is not affected by the transparent middle of latter. That is, the unused track is affected by two masks (from both tracks), but the normal track is affected only by its own. Is that OK? YLSS (talk) 18:18, 17 October 2013 (UTC)

etKRWgl (by Useddenim) uetABZg2 (by Xeror)

That’s interesting. I’ve been taking the opposite approach (where possible). Useddenim (talk) 04:03, 18 October 2013 (UTC)

Well, I wouldn't call that an opposite; cf. Xeror's ÜW-junctions. YLSS (talk) 16:55, 23 October 2013 (UTC)

My own feeling is that where lines are the same colour - as with  (extABZql) - there should be a clear gap along both lines. Where lines are different colours, the "primary" colour (red in the case of e icons, or dark blue in the case of ue icons) should have a normal-looking appearance, and the "secondary" colour (pink or light blue) should be broken as necessary to give a clear gap along the centre of the primary; this is illustrated by  (uetABZgr+r) where the light blue is masked but the dark blue is not. --Redrose64 (talk; at English Wikipedia) 18:14, 23 October 2013 (UTC)

My 2¢ worth is that I prefer the out-of-use line showing through the masking ( (etKRWgl), but I can certainly live with out-of-use masked by both ( (uetABZgr+r). Useddenim (talk) 02:19, 24 October 2013 (UTC)

Mass revision was mostly carried out by Sameboat in January 2014, now finished off by me. YLSS (talk) 07:50, 24 July 2014 (UTC)

Yay! -- Tuválkin ✉ 10:24, 24 July 2014 (UTC)

SNCF electrification sections

was:vSTRsect2-STR & vSTR-STRsect2 was: STRsect1 & STRsect2

These icons show SNCF electrified lines voltage change points between 1500 V and 25 kV / 50 Hz (q.v.) — they have been a bit controversial, said to be uncomprehensible (but so is  (BHF), since stations are not round…), but I think the main issue is that the orthogonal strokes have the same color as the line, making them too similar to things like   (SIDrg).

I therefore suggest its replacement with black strokes, akin to many other established on-line icons such as  (TRAJEKT). Cp. also  (uVGATE) and  (uSTOPLOCK). Opinions? -- Tuválkin ✉ 19:38, 29 April 2013 (UTC)

 Agree. C.f.  (ELC),  (ELC-KS), and the other electrification icons. BTW, I like your new names:  (SEC1) &  (SEC2). Useddenim (talk) 20:11, 29 April 2013 (UTC)

Yes, those “icons on a stick”, widely used in wp:pl in a separate parallel diagram column, also usable (but barely used) as overlays. I’m not sure how those match these, and I should say I dont fully understand how these French icons are supposed to work: They show transition from both sections, but how to mark unelectrified track? In this regard they are a bit like  (WECHSEL), but don’t indicate start/end, only a change point. There was also a   (STRs): IIRC, identical to  (STRsect2) but with a downward half tack. Is it necessary to revive this variant? -- Tuválkin ✉ 20:45, 29 April 2013 (UTC)

Three months later, I started the replacement of the icons with red tacks with the ones with black tacks, as discussed above. Most of the use (about 99%) is in wp:fr, but after a few edits I got this big "ARRÊT" sign from Géofer — who incidentally let the discussion above go by without a squeak. Well, it makes it simpler for me: No need to go around pre-fixing all those diagrams in fr:wp before deleting these icons we all found to be faulty. Right? -- Tuválkin ✉ 14:00, 9 August 2013 (UTC)

(Coincidentally, I created Category:Icons for railway descriptions/electrification for Polish-type icons, as most of these are not overlays. YLSS (talk) 11:53, 4 May 2013 (UTC))

---

Following my request at COM:SPLIT, Ankry ^(thanks!) has merged the original STRsect# files as previous versions of Tuválkin's SEC# files. I hope this will smooth the replacement process while preserving attribution. YLSS (talk) 09:37, 26 June 2014 (UTC)

Well done! -- Tuválkin ✉ 14:54, 26 June 2014 (UTC)

Bad KRWs

Some of these Category:Icons for railway descriptions/krw need to be redrawn with width:100px. -- Tuválkin ✉ 16:17, 26 May 2013 (UTC)

All fixed now, it seems. -- Tuválkin ✉ 02:41, 17 February 2014 (UTC)

Parallel lines ¼ shift and ½ shift

moved to Talk:BSicon/Renaming/SPL#Parallel lines ¼ shift and ½ shift

Tunnellücken

1) uextSTR 2) utLSTR 3) YLSS's proposal 1 4) YLSS's proposal 2 5) Sameboat's proposal

I have concerns about the current design of interrupted lines in tunnel. While the idea is good, and at 500px it looks just fine, in diagrams at 20px it fails. 1) The fact that the dashes are circular and not rectangular is not noticeable at that scale. 2) These circles, being 40px*0.04=1.6px of diameter and centered vertically at 100px*0.04=4px, 8px, 12px, 16px, 20px (that is, at pixel edges, not centers), do not cover a single pixel entirely, with the result that they appear as a bunch of blurred and faded pixels – very much the same as an "ext", not "L" version. So when I observe a diagram containing a "tLSTR", I always mistake it for an "extSTR" and want to fix it!

I have uploaded two new icons:  (utvLSTR-) &  (utv-LSTR) using a different design. For aesthetics at 500px, the dashes are ellipsoid, but of the same size as in non-Lücke versions. For differentiation at 20px, additional whitespace along the line is introduced, pretty much like in  (uSTR) vs.  (uLSTR). I have settled at 75px-long gap instead of the standard 50px (which gives four dashes per icon vs. the standard five in "tSTR"), in the actual coding this looks like stroke-linecap="round" stroke-dasharray="10,115". The result can be seen live at en:Template:IRT Broadway – Seventh Avenue Line against "World Trade Center" and "Cortlandt Street". As an alternative, I also uploaded   (utvLSTR- !), in which the dashes are extended by 10px in order to compensate for slight decrease of area due to curved edges, while the gaps are lengthened to 106.6px; overall this gives three dashes per icon. Please compare and contrast ;) YLSS (talk) 20:59, 13 December 2013 (UTC)

I like the 75/10×115 version! Useddenim (talk) 02:48, 14 December 2013 (UTC)

Hm... And I prefer the second version now... YLSS (talk) 10:19, 14 December 2013 (UTC)

Seeing that Sameboat wrote below that "to me,   (utvLSTR-_!) is still not sufficiently intuitive to tell interruption as opposed to  (utSTR)", maybe let's settle on the 60×106.6 (20×146.6) variant? YLSS (talk) 12:27, 17 December 2013 (UTC)

Back to the topic, here's my suggestion to the new design of LUECKE with opacity gradient:   (sameboat001). This is actually an obsoleted design for CONT set. Unlike the current LUECKE. It requires f/g/r/l/1/2/3/4 suffix to indicate the direction the tracks face toward. -- Sameboat - 同舟 (talk) 05:58, 14 December 2013 (UTC)

Ensuing discussion moved to Talk:BSicon/New icons and icon requests#FADE

Not really related to your topic, but I think using dash stroke to represent tunneled track is the biggest hindrance to BSicon project. To my knowledge, track map in reality uses dash line to indicate obsoleted, planned or constructing tracks, but never track in the tunnel. Most of the time, tunneled track is not differentiated from leveled track or the entrance/exit of the tunnel are indicated by  (PORTALf). To me,   (utvLSTR-_!) is still not sufficiently intuitive to tell interruption as opposed to  (utSTR). Not to mention that I also have trouble to differentiate between  (utSTR) and  (uextSTR). If we want to right the wrong of the t series icons, we should redesign them from scratch, not attempting to improve the current design. -- Sameboat - 同舟 (talk) 04:38, 14 December 2013 (UTC)

Well, IRL dashed lines are used for everything! I just checked some maps at hand (in Russian), and can confirm that underground stretches of a line can indeed be represented with a dashed line, especially when it's not clear which entrance connects to which exit. And if you indeed want to use something else for tunnels... actually, it will be easier to create a new world of icons, or better to invent smart svgs for the whole diagram)). YLSS (talk) 10:19, 14 December 2013 (UTC)

In the UK, Ordnance Survey (OS) maps use solid black lines for railway lines on the surface, double dashed lines for railway lines in tunnel; see for example Box Tunnel which runs left-to-right across the centre of this map; the OS do not depict proposed railway lines. It's not a universal convention: one popular UK rail atlas is

• Baker, Stuart K. (2010) [1977] Rail Atlas Great Britain & Ireland (12th ed.), Hersham: Oxford Publishing Co ISBN: 978-0-86093-632-9.

which uses double lines of dashes for proposed lines, tunnels being shown as single lines of dashes. --Redrose64 (talk; at English Wikipedia) 23:33, 16 December 2013 (UTC)

Thanks for the information, but I think topological map would have a different notation than geographically accurate map as in the example you show. I originally tried to use a chain of glyph like "s" to represent interruption, but Wikimedia's SVG renderer seems to be unable to render textPath so I gave up on the idea. -- Sameboat - 同舟 (talk) 03:00, 17 December 2013 (UTC)

After more experimenting and a lot of staring at different RDTs until my eyes ached, I re-uploaded all icons in question using 58.6×108 (18.6×148) for straights, and 58.6×88+54.6×80.6 (18.6×128+14.6×100.6) for curves. The design with smaller gaps indeed is less intuitively distinguishable from regular tunnel tracks than this one. YLSS (talk) 08:10, 20 March 2014 (UTC)

Curves

tLSTRlf tLSTRrf tLSTRlf tLSTRrf

Useddenim has now re-uploaded  (utLSTRlg) &  (utLSTRrf) using "longer dashes"; you can compare the older design and the newer design to the right. For my part, I certainly dislike those longer dashes: they are even longer than normal  (utSTR) and certainly stand out. However, I agree that three dashes per quarter a circle may not afford enough visual difference from four dashes in  (utSTRrf), maybe two are better. Opinions? YLSS (talk) 10:30, 15 June 2014 (UTC)

Calculation error on my part. The dashes were meant to be approximately the same length as the ones on  (utLSTR). Is   (tLSTRrf) better? Useddenim (talk) 17:24, 15 June 2014 (UTC)

Yup, it is. IMHO, the dashed are still a bit longer than in  (utLSTR), but I'm cool with that. YLSS (talk) 08:10, 16 June 2014 (UTC)

I have tested in   (tLSTRlf) some values closer to those in  (tLSTR), and indeed they look not as good as in your variant. So I re-uploaded them once again with stroke-dasharray="23.6,149.2" for the inner curve and stroke-dasharray="30,189.9" for the outer curve. YLSS (talk) 19:15, 30 June 2014 (UTC)

And I have also overwritten  (utLSTR+4) & co. so that they match with  (uextSTRc1) ( (utSTRc1) should look the same). YLSS (talk) 21:17, 30 June 2014 (UTC)

WARNING! Missing thumbnails

Apparently some boisterous hacker of a developer changed something in the Mediawiki coding without any prior notice, and svg files with no xml tag^{namespace attribute} stopped being converted into png thumbnails. I have re-uploaded  (uLSTRq),  (uexLSTRq),  (uexLSTR),  (exLSTRq) &  (LSTRq), which I encountered purely by chance, but possibly there are others. Please pay attention, everybody. Broken files show a blue version of when browsed via categories; at their description pages it says "(Invalid SVG file: Expected <svg> tag, got svg in NS )"; but in diagrams they may produce something as awful as redlinked "BSicon uLUECKEq.svg" text. YLSS (talk) 18:08, 19 January 2014 (UTC)

So a good deal of these icons were uploaded by me long ago, I removed the XML declaration and XML namespace attribute for reducing file size because they rendered normally in browser. But now even the newest version of Firefox (26.0) refuses to render SVG without proper namespace attribute (<svg xmlns="http://www.w3.org/2000/svg">), but the XML declaration (<?xml version="1.0" encoding="UTF-8"?>) is totally optional (at least at this point) but I think if your SVG contains non-English alphabet it is a good a idea to include it anyway. -- Sameboat - 同舟 (talk) 01:43, 20 January 2014 (UTC)

Yeah, Chrome also requires the xmlns attribute. Does Ü fall outside the English alphabet? ;) YLSS (talk) 06:54, 20 January 2014 (UTC)

Do you mean the content or file name of the SVG file? As for the actual content, W3 validator will warn any XML file without character encoding declaration but still regard it "valid" [1]. As for the file name, the problem is more on the OS and XML editor. I'm using Chinese Windows XP and FirstObject XML Editor to edit SVG codes, if the file name contains non-English character like Ü, when I save the file it will generate a new file which replaces Ü with non-diacritic U which is potentially disastrous to BSicon project. That's why I'm totally against using diacritic alphabet in any file name, even though the German editors should be respected for starting this project, the Ü in the icon ID is causing really ugly problem which should be replaced someday. -- Sameboat - 同舟 (talk) 07:36, 20 January 2014 (UTC)

vÜWor vs. vSTR3

vÜWc2 vÜWor vÜWo+l vÜWc4 vÜWc2 vÜWor vÜWc2 vÜWc4 vÜWo+l vÜWc4 vÜWc2 vÜWc4 vÜWo+l vÜWc4 sameboat002

Please compare & contrast. YLSS (talk) 14:52, 14 February 2014 (UTC)

Not a great fan of v icons, but ÜW set looks smoother. -- Sameboat - 同舟 (talk) 23:38, 14 February 2014 (UTC)

STR looks better on my system (OS X & Firefox). Useddenim (talk) 01:22, 15 February 2014 (UTC)

vSTR3+1 doesn't join perfectly with vÜW, but my point is vÜW set has larger curve radius (better IMO) than vSTR+1。 -- Sameboat - 同舟 (talk) 01:35, 15 February 2014 (UTC)

Ahh, I see now. Yes, the ÜW icons flow better. Useddenim (talk) 12:52, 15 February 2014 (UTC)

So... Do we need both types of icons? In case of  (STR3), the straight part of the curve is negligibly short (from (36,464) in one cell to (464,36) in the other). In case of parallel lines, a large part of the curve has to be straightened. Is there enough aesthetic difference to keep both series? If yes, I can't think of a better name for   (vÜWor) (which isn't actually Überwerfungsbauwerk). YLSS (talk) 13:36, 15 February 2014 (UTC)

I don’t see any need for two sets of icons that are functionally identical. If the mis-match of the corner icons can be fixed (hello Tuvalkin?) we can can jettison the vSTRs. Useddenim (talk) 18:14, 15 February 2014 (UTC)

Erm... what do you mean? What corner icons? Mis-match with what? Of these icons, Tuválkin only uploaded  (vSTR3+1), and it's 101% correct. My intention was that e.g.   (vÜWor) would be merged as a previous version of  (vSTR3). YLSS (talk) 20:36, 15 February 2014 (UTC)

Um, I meant that Tuválkin seems to like to play around with these and make everything line up correctly (as IIRC he did with the SHIc icons). On my display there’s a little “hiccup” where the vÜWc icons abut  (vSTR3+1). Useddenim (talk) 22:26, 15 February 2014 (UTC)

Sorry I didn’t replied this earlier. I  Support remaking/keeping corner icons of double lines perfectly straight, unlike in my original choice with  (vÜWc2) etc. (back then we didn’t have any diagonal doubles, I think, and this is was made just to create a double size shift). As for the names, I favour STR over ÜW, of course. -- Tuválkin ✉ 00:37, 17 February 2014 (UTC)

I suppose you mean  (dvÜWc2)?  (vÜWc2) was uploaded by Vunz back in 2009. Also, I may note that your  (uvÜWc2) is already straight. YLSS (talk) 06:34, 17 February 2014 (UTC)

I made a different version of vÜWo+l/vSTR+1 with quadratic bezier curve command (q) for simplicity and maximal curvature. I tried to use elliptical arc command (a) but it's very hard to get the right values. Each time you adjust the radius, the destination of x and y need to be calculated again in order to match vSTRc4/vSTR3+1. My curves, especially the inner one, are not yet perfect and may need further fine tuning.

M 125,525 v -25 q 0,-310 162,-464 l 200,-200
M 375,525 v -25 q 0,-195 90,-288 l 200,-200

-- Sameboat - 同舟 (talk) 02:26, 17 February 2014 (UTC)

Why bezier curves, even if quadratic? It's the circular arcs that provide the maximum radius of curvature. That is, other curves may have a greater radius at some point, but only because they will have a smaller radius at another point. In your version, curves are certainly more steep just before they become aligned at 45°. Additionally, circular arcs guarantee that the distance between the parallel lines equals 250px all the time. [Not that I foresaw that, TBH ;) I just calculated circular arcs that would be tangent to vertical lines from (125,500) and (375,500) on the one hand and lines at 45° from (411.6, -88.4) and (588.4, 88.4) on the other (88.4 ≈ 125×√2/2), which would only start curving after they have completely entered the icon ((36,36) from the entering point at the edge, 36 > 50×√2/2). Quite unexpectedly, I arrived at 553.8 and 303.9 as radius values (difference ≈250), and the same ordinate of the endpoint for both (427.7). I could have foreseen that...] YLSS (talk) 06:28, 17 February 2014 (UTC)

Then I support your vSTR+1/3 and redirect from vÜW. -- Sameboat - 同舟 (talk) 08:41, 17 February 2014 (UTC)

---

I've re-uploaded all the icons concerned, as well as renamed them to vSTR. Most frustratingly, looking at the pictures to the left makes me think that it may be better to set the half-distance between diagonal parallel lines to 500 * √2 / 6 ≈ 117.85px instead of 125px as with vertical & horizontal parallel lines (if you get what I mean), but that would mean re-uploading them once again... What do others think? YLSS (talk) 17:24, 2 May 2014 (UTC)

I have now uploaded a whole set of double ÜW-curves in black, but with 117.85px as half-distance between the diagonal parallel lines. The result can be seen at ru:Шаблон:Центральные станции Московского метрополитена. The blue diagonal lines and the black ones are now separated by at least a bit (before they were too close), and it will become a bit larger when the "u" set is re-uploaded. So unless anybody protest, I'll re-upload the "bahn" and "u" sets. OK? YLSS (talk) 23:04, 18 May 2014 (UTC)

 Done. Since nobody responded to this monologue of mine, I went ahead and re-uploaded all the icons. Personally, I find the pictures to the left far more pleasant now. The coding is also somewhat simpler, being based around 83.33/166.67/333.33/416.67. However, it would still be interesting to know whether all this was a monologue towards an audience or a monologue into the emptiness... YLSS (talk) 16:50, 8 June 2014 (UTC)

No comment because I had no objections… Useddenim (talk) 20:28, 8 June 2014 (UTC)

Audience, here, too! :-) -- Tuválkin ✉ 20:07, 10 June 2014 (UTC)

Design of 45° curved splits

 (uSPLe+4).

 (SPLe+4) vSTR+4e, should be renamed SPLe+4.

Okay, so which do you prefer, and why? -- Tuválkin ✉ 19:26, 4 May 2014 (UTC)

(Please comment in the section directly above before making any uploads!)

( (vSTR+4e) should be re-uploaded in any case, because it doesn't align well with the updated  (vSTRc3) & co.)

I really dislike any backward curves (such as in  (vSTR+4e)) because they tend to show up when they aren't expected to, e. g.  . Except in some inherently ugly icons, such as  (STR3+1h) or  (dSTR3+l)), they should be avoided. That said, I agree that  (uSPLe+4) doesn't look good, but I don't know how to improve it. Maybe using more than one stroke at the top (thickening it a bit)? YLSS (talk) 20:21, 4 May 2014 (UTC)

I understand the problem with the bulging curve, yes, I didn’t notice it before. However I don’t know how to improve this matter, either. :-( -- Tuválkin ✉ 01:27, 16 May 2014 (UTC)

Hmm, does the "u" split look better now? I have re-uploaded it with the distance between diagonal lines = 117.85px (see above), and as a side effect the curves became more gentle. YLSS (talk) 14:08, 6 June 2014 (UTC)

Anyway, I've re-uploaded the "bahn" splits as well, just so that they match the modified  (vSTR3+1) etc. If anyone has a better idea on their geometry, feel free to upload it. YLSS (talk) 16:50, 8 June 2014 (UTC)

vKRWs

moved from Talk:BSicon/Renaming/SPL#vKRWs

Geometry matches uvSHI2l | vSHI2+r-|O2=v-SHI2+r   vSHI2l-|O1=v-SHI2l | uvSHI2+r   Mismatched lines vKRWl | vSHI4+r-|O2=v-SHI4+r   vSHI4l-|O1=v-SHI4l | vKRW+r

Why vKRWs and not vSHI4s? I though to limit "KRW" & "BS2" only to classical non-parallel full-width icons. (Tuválkin seems to be willing to go even further [2].) YLSS (talk) 05:39, 17 March 2014 (UTC)

I knew you’d ask. Have you overlaid your vSHI4-s with v-SHI4s? It’s not pretty:   vs.  (vKRWl)—the geometry doesn’t work. Useddenim (talk) 10:25, 17 March 2014 (UTC)

Yup, but I don't speak about geometry, only about naming.  (vSHI2l-※ v-SHI2l)  ≠  (vSHI2l), but that doesn't mean that they should be named differently. YLSS (talk) 12:28, 17 March 2014 (UTC)

Sure it does: if they don't match up, then they shouldn't be named the same. Useddenim (talk) 01:36, 19 March 2014 (UTC)

I can't say that I like that logic. If we follow it, then  (vKRWl) should match up with  (KRW+r), while  (STR2h+r) and  (BS2c3)/SHI2c3 should not. Indeed, may I remind you that  (uvSTRal) as you originally draw it did not match with anything except  (uvSTRc3), not even  (uvSTRel); but in that case there is only one line crossing into adjacent cell, and it was easy to adjust the crossing point to the "orthodox" midpoint, so that it would match up with a dozen other icons. In  (vKRWl) there are two such lines, so it can only match with  (vKRW+r) (give or take ). YLSS (talk) 06:26, 20 March 2014 (UTC)

Then what do you propose as a solution? One possibility is to redraw  (vSHI4l-),  (v-SHI4l) etc. to match  (vKRWl). Useddenim (talk) 12:05, 20 March 2014 (UTC)

No, I do not propose any redrawing, all icons look just fine! They just cannot be user together, as far as I can foresee. I only think that this doesn't prevent all of them to be named using vSHI4; IMHO, but I don't insist... YLSS (talk) 13:42, 20 March 2014 (UTC)

How about this:  (vSHI4l-),  (v-SHI4l),  (vSHI4l),  (vSHI4l-L),  (vSHI4l-R) ? YLSS (talk) 21:02, 4 May 2014 (UTC)

Design of curves with corner arrows from mid-side to corner

 (uCONT1+r).

 (uexCONT4+l)

(One more of these:) Okay, so which do you prefer, and why? -- Tuválkin ✉ 17:39, 10 June 2014 (UTC)

Ah, not a matter of intentional design variation: At 180px these show (symmetrically) identical. However at 20px (in diagrams) and 120px (categories),  (uCONT1+r) and  (uexCONT1+r) look smooth to me, while the rest looks crooked (same issue with the bahn red icons). See this screenshot from Category:Icons for railway descriptions/set u/continuation/curve/to corner:

File:BSiconLibSVGbug.png

Seems to be a matter of LibSVG bug, but I stared very hard at the SVG code for a few minutes and didn’t find any suspect difference. -- Tuválkin ✉ 17:58, 10 June 2014 (UTC)

Forget it, it was just my cache not reflecting YLSS’s brand new, smooth design. I was going to say I prefer it, but I guess we all do. -- Tuválkin ✉ 18:04, 10 June 2014 (UTC)

BSicon/Icon geometry and SVG code neatness

(If somebody didn't notice...) I started that one so that all samples of coding can be gathered at one place, without the need to consult some similar icon (which may actually show some bad coding). Additions and corrections are welcome. Possibly some links to that page should be added at en.wp and elsewhere, so that people would be readily aware of it. YLSS (talk) 10:37, 24 July 2014 (UTC)

I was just thinking that we needed something exactly like this, yesterday. Great work! Lost on Belmont (talk) 11:57, 24 July 2014 (UTC)

My thoughts exactly, very very good! -- Tuválkin ✉ 10:57, 25 July 2014 (UTC)

"et/xt" set icons need additional instruction because they use 2 separate masks. -- Sameboat - 同舟 (talk) 11:32, 25 July 2014 (UTC)

Much better than my abortive start at en:WP:RDT/C#Geometry (although you may want to copy the text from there into the intro). Useddenim (talk) 12:22, 25 July 2014 (UTC)

Geometry of paralel lines across curving 45°

• 
• 
• 
• 

For some reason, things like  (vSTRl+4) and  (vSTR3+l) look much less good than, say,  (vSTR3). Is there a good reason for it? -- Tuválkin ✉ 14:35, 16 October 2014 (UTC)

Erm, what? Can't see any difference. YLSS (talk) 15:07, 16 October 2014 (UTC)

I just created  (vSTR3_teal) from  (vSTRl+4) with a −90° rotation and… it’s shape is exactly identical to  (vSTR3). So, forget it, I was/am seeing things that aren’t there! -- Tuválkin ✉ 16:23, 16 October 2014 (UTC)

L3STR

@Useddenim: maybe better to use stroke-dasharray="0.01,121.7" for  (L3STR2) and stroke-dasharray="0.01,129.8" stroke-dashoffset="32.2" for  (-L3STRq) ? That is closer to stroke-dasharray=".01,124.99" in  (LSTRq). The upper halves of the rosary beads to the right look closer to each other than the lower halves do. I maintained the possibility of pairing  (3STRq-). YLSS (talk) 11:38, 17 November 2014 (UTC)

I think the tighter dotting looks better and more like what is in use already. And kudos for the  (3STRq-) joining possibility! -- Tuválkin ✉ 22:52, 17 November 2014 (UTC)

I had considered 4 dots (3 + 2×½) instead of 3 (2 + 2×½), but felt that it looked too crowded. However, after making this comparison:

(LSTR)	(LSTR+1)	(L3STR+1)	(LKRW+l)	(LSTRrg)
	(LSTR2)	(L3STR2)	(LKRWl)	(LSTRlf)

I see that  (L3STR2) is out of sync.
But I don’t understand why Tuvalkin suggests that doesn’t join up properly. Useddenim (talk) 17:49, 22 November 2014 (UTC)

I didn’t suggest that — both 3- and 4-dot versions seem to connect seamlessly. Anyway, seems that we all agree that that 4 dots is the way to go. :-) -- Tuválkin ✉ 19:17, 22 November 2014 (UTC)

Off-topic

Do we really need another curvature? Especially three icons that can't be combined with any other icon (horizontally)?? a×p_de^Hello! 15:10, 17 November 2014 (UTC)

You've been away for too long, Axpde ;) Yes, this is quite a brilliant invention by Useddenim, 3ABZs. They make some diagrams look really authentic – just the way railways are constructed in reality. Check these for example: 1, 2, 3, 4, 5. YLSS (talk) 16:09, 17 November 2014 (UTC)

In dewiki some users deny the need to have those BSicons for a simple reason:

"No matter how many BSicons you create, a real map always looks better!"

I never had any problems to use STRlf and so on. I never tried to reach perfection with BSicons, because that not what they were invented for. BSicons should help to make an abstract from reality, nothing more. That's why I don't think we need all those very-very-very-special BSicons which are only very seldom useable. Greets a×p_de^Hello! 18:08, 17 November 2014 (UTC)

Cleanup for water icons?

I've been working to complete my rail project on my talk page and I noticed that the geometry of two water icons don't quite work so well. I would think that either a small change to the existing icons can fix this, but perhaps new icons are in order.

Thoughts? BT14 (talk) 00:45, 21 December 2014 (UTC)

 (WDOCKSc3) is intended to create a smooth junction to an icon with a straight upper edge, not with  (WDOCKSlg). It will also align with  (WDOCKSr), or with  (WDOCKSr※ WDOCKSa) . However, I admit that radius = 200px in these icons may not be the best option. Possibly 250px, 150px or maybe even 187.5px would be better. (The last one would permit a tight aligning with  (WDOCKSr), shifted by  (c) to the left.) YLSS (talk) 13:54, 22 December 2014 (UTC)

I made the radius 200px by reverse engineering the original 'WDOCK' icon. What's the radius for a standard STR turn? 250? User:Deonyi 23:53, 23 December 2014 (UTC)

Yes but;  (STRrf) etc. use a 100px-wide line, so the inner edge is r = 200 and the outer edge is r = 300. Useddenim (talk) 16:44, 24 December 2014 (UTC)

(If in doubt, consult BSicon/Icon geometry and SVG code neatness! )

WRT changing the radius... Yes, switching to 250px would be the easiest solution, but while  (WDOCKSc3) or   (WDOCKS-Re) would look OK with any radius, some  (WDOCKSr) would look different than now, and  (WDOCKS) would degenerate into a large circle. So either leave it as it is, or change it to 187.5px. YLSS (talk) 20:55, 24 December 2014 (UTC)

BHFCC & BHF+TUNNEL

Following the discussion at Talk:BSicon/Renaming#BHFCC & BHF+TUNNEL

Portal location for tunnel entrance at icon edge

moved to Talk:BSicon/Icon geometry and SVG code neatness/Formations#Portal location for tunnel entrance at icon edge

Transition stations’ design

[Transition stations] should be drawn as   and  . (It doesn't show too clearly, but the tunnel portal spans the station, which is a not-uncommon occurrence. Useddenim (talk) 23:49, 23 February 2013 (UTC)

I agree with the proposed semantics, but the portal probably shows poor contrast for most track colors, surely so for the current lines’ colors as shown above (and not less so for   and  ). Maybe draw it with white #f9f9f9 outlining to make the station show through, akin to the unusual (but necessary) special icons  (TBHF-Mu) and   (BHFgl+l)? -- Tuválkin ✉ 14:20, 24 February 2013 (UTC)

Agreed. Useddenim (talk) 17:59, 24 February 2013 (UTC)

Red roads

MROADq

MWSTRq

While on the topic of theses, now might be the right time to raise the issue of their colour and width:

	MROAD		MW		Width
	red	yellow	red	yellow
Current	ff0000	ffff00	e07070	f0f080	120
Standard	ef161e Set red	ffd702 Set yellow	f37176 ex-red	ffeb81 ex-yellow	100

These changes are illustrated with the existing on the left, and standard colours on the right:

Useddenim (talk) 00:23, 18 June 2013 (UTC)

I’m neutral about changing the colors, but against changing the width — because complex junction icons such as  (MWABZlgu) or  (MWEXrfu) would have to be redrawn from sctatch to match 100px thick roads. -- Tuválkin ✉ 12:15, 18 June 2013 (UTC)

Elliptical curves

moved from #Why blue and red with different designs for the same topology?

While some have been justified, some don’t seem to have a reason to be, such as   (exSTR+r-ABZg+r) vs.   (uSTR+r-ABZg+r) (and maybe others to come to here) — cp.   (exvABZaq+r) vs.   (uvABZaq+r). Why? --Tuvalkin (talk) 14:22, 1 October 2011 (UTC)

I didn't like the curvature of the original, so I made a new design with rounder curves that are closer to  (uSTRlg). I don't see any conflict, as they're not both used in the same diagram. Useddenim (talk) 16:14, 1 October 2011 (UTC)

Part of the "issue" is that blue icons are also created and designed independently by the Canal project members, leading to conflicted designs. Circeus (talk) 17:32, 1 October 2011 (UTC)

In my opinion, all icons should share the same basic geometric “style”; one of the elements of that style is that curves should be (and mostly are) as wide as possible within the icon boundaries, therefore   (exSTR+r-ABZg+r) is right and   (uSTR+r-ABZg+r) is wrong. The fact that some icons tend to be used more for a given subset of of diagrams (either by usage or by language version of wp) is immaterial and justify stylistic variation based on it defeats the goal of centralizing these icons under a single family in commons. --Tuvalkin (talk) 19:10, 1 October 2011 (UTC)

I'm not justifying, I'm explaining. Similar issue plague the AKRZ icons becaus eof different u- designs. Circeus (talk) 19:33, 1 October 2011 (UTC)

---

Ellipse Bezier curve

I’ve never been particularly fond of the elliptical curves used for the non-circular 90° turns. What are others’ opinions of this alternative design that uses Bezier curves and a “straighter” connection to adjacent icons? Useddenim (talk) 01:11, 6 December 2013 (UTC)

uexSTRl-   uexSTRl-!

Yup, I also found them ugly. For simple small curves, your design looks better, IMHO. However, for junctions with a straight track, especially if there are curves from both sides, not very much of a curve can be seen. Maybe we should use different designs? Also, what about  (uex-STRl)? YLSS (talk) 08:00, 6 December 2013 (UTC)

 (uex-STRl!) (Bezier curve) or  (uex-STRl!!) (circular curve). Useddenim (talk) 04:55, 7 December 2013 (UTC)

I've got no problem with elliptical curves. After all, a circle is a special case of an ellipse, and we've been quite happy for several years using circles in  (STRlf) etc. --Redrose64 (talk; at English Wikipedia) 17:02, 6 December 2013 (UTC)

Of course, circles are ideal! They have a constant radius of curvature, namely 250px. For "small" ellipses like  (uexSTRl-), the radius of curvature at the top is 75px – too steep! For  (uex-STRl), it is 166.7px at the right edge – tolerable, but the gentle 250px would be better still. YLSS (talk) 19:03, 6 December 2013 (UTC)

I wish to add my own humble opinion: The previous version of the now changed curves, drawn using elipse arcs, was right. These new curves, drawn with bezier vectors (any curve could be done with beziers, that’s not the issue) are wrong — both esthetically and semantically. I regret that this change was even considered (its shortcomings being obvious), let alone implemented. -- Tuválkin ✉ 19:06, 27 December 2013 (UTC)

Please elaborate! What are the shortcomings? They are not as evident as you think ). I can only think about the branch protruding less distinctly when there is a straight track; but for that we can have a separate icon. On the other hand, diagrams such as this now look better than before. YLSS (talk) 20:49, 27 December 2013 (UTC)

Bordered feature

Although it looks like a small depot by the side of an undetailed light rail line, this is supposed to be a «feature on [proposed/disused] waterway», which is fine by me, but could the thin black border go? It just makes the icon look “dirty” at lower sizes. -- Tuválkin ✉ 17:15, 26 September 2014 (UTC)

Mixed color?

While these are set-u blue the feature is bahn-red, I’m almost sure that that has no significance. These 5 icons should in my opinion be either recolored to u-color, or renamed using the m preffix. -- Tuválkin ✉ 18:13, 26 September 2014 (UTC)

Synonym?

And how does this compare to the footpath equivalent?

•  (fOBJl)  ≟  (uSTRfl)
•  (fOBJr)  ≟  (uSTRfr)
•  (fOBJrl) ≟  (uSTRfr※ uSTRfl) 

Shouldn’t these two families be joined? -- Tuválkin ✉ 18:13, 26 September 2014 (UTC)

Re-invent?

In order to show that it's a feature unrelated to the canal/track in question and to reduce the similarity to  (lv-BST) etc. (which is really close), I would propose the following. a) I wanna see it painted, painted, painted, painted black, like  (uSTRbl); and b) possibly find a better symbol, and indeed merge this same concept in the "u" & "f" sets. As it is,  (uSTRfl) and similar are used for pretty much anything, mostly for settlements near a canal, but sometimes for particular buildings, hills etc., so some of the usage should probably be replaced by  (uSTRbl)... On the other hand,  (fOBJl) & co. are used for buildings, reservoirs, hills, stones etc. etc. So I think it's better to replace some of its usage with  (BUILDINGl),  (uexlvHST),  (lGIPr),  (lNATRr) and so on. So we need something pretty generic for anything that remains. But I'm bad on ideas about new symbols, so... any proposals? YLSS (talk) 19:16, 26 September 2014 (UTC)

Well, canals using that icon for a village or settlement potentially be changed to use  (upBHF) or  (upHST) or one-way versions to show sides? Houses or specific buildings could use the  (BUILDINGl) Other things could be shown with a solid black dot.User:Deonyi 05:18, 29 September 2014 (UTC)

• I think that something that looks like  (lBST) and yet is not a minor depot or goods station really needs to go, and I also think that the tilted square of  (fOBJrl) is a great design that should be kept and expanded (but also redrawn for regularity, though, and renamed). -- Tuválkin ✉ 11:15, 29 September 2014 (UTC)

  Why not, in the end. But what do you mean: black or green (/blue/red/as main track)? YLSS (talk) 12:51, 29 September 2014 (UTC)

I would prefer the black diamond (◆—Unicode 9670, hex 25C6), as it is unused, and not similar to anything else (except maybe  (lGIPl). Useddenim (talk) 21:08, 29 September 2014 (UTC)

The diamond black or line color? Frankly, I’m undecided. I can see advantages in both. -- Tuválkin ✉ 02:49, 5 October 2014 (UTC)

Heh, please elaborate! Not that I argue, I'd just like to read them and to think on them. YLSS (talk) 09:47, 5 October 2014 (UTC)

New icon KHSTeeBHF

I've just found   (KHSTeeBHF), created by PupyFaki (talk · contribs). It looks horrible - the central disc is a polygon, and the outer ring may be a polygon as well; there seems to be a binary component in the form of an ‎<image /> element. It also doesn't seem to fit in with any established naming convention. It also seems redundant to  (eKBHFe). --Redrose64 (talk; at English Wikipedia) 18:06, 26 September 2014 (UTC)

Yes, yes, at the very least it should be re-uploaded with a proper SVG file. And I'm not sure about the name: while derived from  (HSTeBHF), I would expect such a name to show  , and this one should probably be   (KHSTeeKBHFe) – or can it be contracted to   (KHSTeBHFe) ? But of course, the main question is: Do we need it?, as it is pretty redundant (not to  (eKBHFe) but) to the overlaid pair  (KHSTe※ exKBHFe) . It.wp permits icon overlaying, thanks to me ;). YLSS (talk) 18:48, 26 September 2014 (UTC)

Overlaying doesn’t reflect Useddenim’s slight difference of  (HSTeBHF) from  (HST※ exBHF) ; the filename is tricky too, when terminuses are considered: Two roots should have a plus sign for overlapping, and "ee", while logical, is hard to recognize as the 1st "e" meaning end station and the 2nd meaning disused. That’s why I uploaded the following:

•  (KHSTe+exKBHFe) (oops, this must be deleted, then   (KHSTeeBHF) renamed   (KHSTe+exKBHFe), and then its 20 kB contents replaced with the new file’s)
•  (KHSTe+exBHF)
•  (KHSTa+exBHF)
•  (KHSTa+exKBHFa)

-- Tuválkin ✉ 19:40, 26 September 2014 (UTC)

A possible solution. But once again we have the question of the root listing order. Why the regular first? I would list them just as they are overlaid: exKBHFe+KHSTe etc. YLSS (talk) 19:52, 26 September 2014 (UTC)

Good point. Maybe the opposing argument is that the most visible comes first, and the plus sign means "over", instead of "under"? -- Tuválkin ✉ 21:03, 26 September 2014 (UTC)

You mean like ∘ in function composition or like ※ in {{Bs-o}}? Well, of course it's equally workable, but I would favour the same order as in wikitext, just to ease the possible conversion (and also to ease the understanding): cf. STR+GRZq ~ STR|On=GRZq ~ STR\GRZq (in Lua syntax). Personally, I always have to double-check myself because {{Bs-o}} uses the reversed order. YLSS (talk) 21:40, 26 September 2014 (UTC)

Renamed them accordingly, as I consider it quite important to maintain the said equivalence. I didn't bother to preserve the original file from   (KHSTeeBHF) because, with all due respect, 20kB is a bit too much to preserve ;) YLSS (talk) 23:36, 29 September 2014 (UTC)

Compare  (HSTeBHF) with  (HST), the red dot is smaller! Actually I created  (HSTeBHF) (just see the comment inside the svg) in 2007. On dewiki we talked about this icon in December 2007, see de:Wikipedia Diskussion:Formatvorlage Bahnstrecke/Archiv II#Neues Bild, and decided not to use it because visual impaired people would have big problems. a×p_de^Hello! 11:38, 31 October 2014 (UTC)

Furthermore we had some experiments as BSicon HSTeBHF r.svg, FYI. a×p_de^Hello! 11:42, 31 October 2014 (UTC)

Yeah, TBH, I also didn't like that shrunken HST. How about  (HSTeBHF!) ? You can play with gradient's stop-offsets. YLSS (talk) 12:30, 31 October 2014 (UTC)

Ping everybody: any comments? YLSS (talk) 18:31, 4 November 2014 (UTC)

I like it. -- Tuválkin ✉ 18:57, 4 November 2014 (UTC)

It seems that the clarity of the icon is dependent on the browser and monitor used… Useddenim (talk) 20:05, 4 November 2014 (UTC)

Um, what do you mean? How does it look for you? And as I said, feel free to try out different stop-offsets. IMHO, in comparison to a white circle, gradient a) permits more flexibility, and b) definitely looks better at larger sizes. YLSS (talk) 20:34, 4 November 2014 (UTC)

Looks good to me. Lost on Belmont (talk) 03:32, 5 November 2014 (UTC)

How wide is narrow?

So,  (unSTRrf) is 40px thick, while  (unSTRq) is 50px — which is the good one? -- Tuválkin ✉ 19:08, 1 October 2014 (UTC)

I thought we standardized on 50px. Useddenim (talk) 00:16, 2 October 2014 (UTC)

That's only the tip of the iceberg.

• Set bahn: mostly 50px, but some 40px
• Set u: mix-up of 40px & 50px (some fixed to 50px by Tuvalkin, some not)  All 50px now -- Tuválkin ✉ 12:44, 4 October 2014 (UTC)
• Set g: 40px  50px now -- Tuválkin ✉ 11:30, 4 October 2014 (UTC)
• Walkways / set black: mix-up of 40px (older) & 30px (newer, especially exBLs)
• Electrification lines: 30px

While I totally agree that "regular" narrow icons, i. e. sidings, feeders etc., should be 50px, the walkways are a problem.  (exBL) is used only for planned electrification lines, not for walkways. Possibly we should set up two parallel black sets: one 50px-thick and another 30px-thick? YLSS (talk) 07:57, 2 October 2014 (UTC)

I think having them all at 50px should be fine. There isn't any need nor requirement for multiple. If there is confusion, labelling should suffice.User:Deonyi 09:55, 2 October 2014 (UTC)

The BL family should be standartized independently of the convention for narrow lines. Black narrow lines would be (if necessary to create them) named   (nSTR_black) etc, anyway, not  (BL) etc. -- Tuválkin ✉ 01:28, 5 October 2014 (UTC)

I'm also inclined to think that BLs can be kept separate from nSTRs, despite the fact that this was Useddenim's original motive which led to the introduction of the nSTRs! ;) But if so, I think BLs should be thinned down to 30px to make them more distinctive and fully integrate with the ELCs. @Sameboat: AFAIK you are the original creator of BLS, what do you think? P.S. There would be no benefits of switching to 25px as the line would in any case be centered in the middle and there would be no fully covered pixels at 20px. YLSS (talk) 09:39, 5 October 2014 (UTC)

No comment really. Whatever the thickness or ID, their original intention as pedestrian link (as in template:HK-MTR route/Tsuen Wan) won't be affected. Even if you round the angled BLs (e.g.   (BLlf) into sth similar to  (unSTRlf)), the change of cognition is minimal. -- Sameboat - 同舟 (talk) 01:20, 6 October 2014 (UTC)

@Tuvalkin: simply changing 40px to 50px doesn't work. The geometry is faulty, so the line becomes de-centered. YLSS (talk) 12:50, 4 October 2014 (UTC)

Duh!, you’re right! Those made with rect instead of path need to be yes thinned down 10 px but also moved around 5 px. I’ll do that now. -- Tuválkin ✉ 14:22, 4 October 2014 (UTC)

Just to cause trouble: the  (GRZ) set is 40px. Useddenim (talk) 21:39, 4 October 2014 (UTC)

It would be troubling if some were 35 or 45 px instead of 30. As it is, the  (GRZ) family cannot be mistaken for the narrow form of anything — too different from any possible lücke or tunnel version of the black set, especially if/when the gaps of GRZ become white for all icons. So, no trouble (unless we decide that both GRZ and BL should be resized to, say, 25 px…) -- Tuválkin ✉ 01:28, 5 October 2014 (UTC)

Redraw parallel junction+crossing?

I know the matter was discussed a while ago, but I’d like us to rethink it. Truth is — comparing  (vKRZu-ABZg+r) with  (v-STR※ vKRZu-STR+r) , the latter looks much better… And that’s a reason good enough for me to think the former (and its whole family) should be redrawn to match it. Any thoughts? -- Tuválkin ✉ 02:44, 5 October 2014 (UTC)

Of course. It's one of the items in my long long list of to-dos. Previously I uploaded them with the curve M 300,250 H 280 C 150,250 125,400 125,500, as in  (veABZg+l-eKRZo) or with M 500,250 H 315 C 200,250 125,320 125,500 as in  (veABZg+l-eKRZu) (for some strange reason I maintained that dichotomy). Lately I switched to circular arcs M 500,250 H 325 A 200,200 0 0 0 125,450 V 500, as in  (vxABZg+l-xKRZu),  (vxKRZo-ABZgr) and the whole family of curve+crossing icons. I don't know about any previous discussions pertaining to this particular set of icons, except Vunz's comment "All icons have the same look and feel and are interchangeable with half width icons." at  (veABZgl-eKRZ) — and I find it quite laughable now! YLSS (talk) 09:27, 5 October 2014 (UTC)

bvWSL-BS2lr et al.

		original:  (bvWSL-BS2+lr)
		equivalent to  (BS2+l)※ (STRrg) and  (BS2+r)※ (STRlg)

See also Talk:BSicon/Renaming#bvWSL-BS2lr et al.

I have tried to upload new versions with thinner strokes and redrawn curves with improved clarity and visibility, but Axpde keeps restoring his original versions which obliterate the white triangle in the middle. Any thoughts? Useddenim (talk) 10:16, 31 October 2014 (UTC)

I designed those icons to exactly match other icons I created.

And because of  (ABZgnl) I strongly disagree with line widths other than 100px and 50px!

Cheers a×p_de^Hello! 10:48, 31 October 2014 (UTC)

(Finally, you two stopped reupload-warring and brought the issue here!) Personally, I'm undecided on this issue... I agree that  (ABZgl+l),  (vÜST),  (bvWSL-BS2+lr) and others look quite blurred if drawn with 100px-lines only, but at the same time I can't say that I like thinning them to 80px/70px or anything. (50px is OK, but only when used with implication that it's a single track instead of two, as in  (vÜSTBl).) Useddenim's version of  (bvWSL-BS2+lr) from 26 October 2014 is IMHO too thin, but I see good sides both to his later version and to Axpde's. YLSS (talk) 11:04, 31 October 2014 (UTC)

Redrawing

original:  (bvWSL-BS2+lr) ubvWSL-BS2+lr 80 px lines:   (ubvWSL-BS2+lr) Tuvalkin’s idea:  (BS2+l)※ (-STR+l) and  (BS2+r)※ (-STR+r) uexbvWSL-BS2+lr YLSS’s idea: modified curves:   (uexbvWSL-BS2+lr) ubvWSL-BS2+lr uexbvWSL-BS2+lr Same as above, in 20 px.

Tighter inner curve

Regardless of other aspects, let me suggest a possible solution: To redraw the bottom-to-bottom leg of the wye as a tighter curve, extending only to the height of the lower line of an imaginary horizontal double track line, as in the blue example at the right. -- Tuválkin ✉ 20:04, 1 November 2014 (UTC)

Note that this (375 or 125, instead of 250) is also more or less how “deep” into the icon area that wye legs go in icons such as   (WYEg+23). -- Tuválkin ✉ 20:17, 1 November 2014 (UTC)

Well, yes, the triangle is definitely visible in this example, but it doesn’t have the same elegance as a circular curve. I have used this construct, but didn’t like it, which is what prompted me to start redrawing the double-width icons in the first place. Useddenim (talk) 20:37, 1 November 2014 (UTC)

Agreed, but we need to trade off something: Either visible triangle with iffy curves, or elegant curves and shrunken triangle. One-fifth is just too small for this kind of complexity. -- Tuválkin ✉ 00:59, 2 November 2014 (UTC)

Double icon = 1+1 regular ones, or not?

Hm, let me withdraw this suggestion, at least as a way to redraw these wye icons: Not only because it can be recreated by trivial overlaying of existing icons, but also because, if applied also to half split icons (as any design change in these double-wide icons should be), it renders impossible this kind of smart stuff (suggested by none less than myself!). -- Tuválkin ✉ 13:55, 2 November 2014 (UTC)

We don’t have to have the double-width version identical to the single pairs. We don’t impose that requirement on half-width icons; and as long as an icon joins correctly at the edges, I say “Make it look as neat and elegant as possible.” (So my vote is for YLSS’ modified design.) Useddenim (talk) 17:59, 2 November 2014 (UTC)

Actually, it does permit splitting to halves such as  (uexSTRl+uSHI2l). The only difference is that if used with anything else than  (uexSTRr+uSHI2r), it would require not  (uBS2c3) but  (uSHI4c3) (which is tolerably close). But yes, Useddenim is right, we should cheat the system in this way only in dedicated icons — and that's their purpose. YLSS (talk) 18:20, 2 November 2014 (UTC)

@Axpde: what do you think about this? YLSS (talk) 15:47, 2 November 2014 (UTC)

Those icons only exist because of dewiki lacking overlay, and that's just what I did, I overlaid  (exSTRlf) with  (BS2l) and I got  (BS2l※ exSTRlf) . I did this on purpose and didn't introduce new curvatures to keep it smart and simple. And I still think this is the only way to handle this! Greets a×p_de^Hello! 17:34, 2 November 2014 (UTC)

Well, there are other points in the existence of these and other complex icons. First, they usually simplify coding (yeah!), and second, they permit to create more elegant or more clear diagrams. E.g. looks better then  ; looks better than ; and we can make look better than   . Don't you agree with the benefits of that? YLSS (talk) 18:20, 2 November 2014 (UTC)

In other words, Axpde, IDL. See my comment above, in #Tighter inner curve. Useddenim (talk) 18:43, 2 November 2014 (UTC)

Wider outer curves

May I suggest another option: using the same geometry for BS2s as for the outer curves of  (vSHI2+l) &  (vSHI2+r). YLSS (talk) 21:59, 1 November 2014 (UTC)

I created a new  (BS2+r_purple) using the longest stroke from  (vSHI2+r), and used in the diagram at the right; the already existent  (BS2+l_purple) uses the usual BS geometry and presents an interesting contrast. -- Tuválkin ✉ 00:59, 2 November 2014 (UTC)

I think we may have a winner here. To me this satisfies Useddenim's requirements of curve elegance and triangle white space. Lost on Belmont (talk) 02:47, 2 November 2014 (UTC)

OMG OMG! Rename Delete it swiftly! I never meant it for a stand-alone BS2, only for a part of this complex icon! Simple BS2/SHI2 should be symmetrical, of course. YLSS (talk) 09:17, 2 November 2014 (UTC)

Chillax, man! ;-) That’s why I made it purple, a scarcely used set — to be able to play with it while ruining no diagrams out there. Sure  (BS2+r_purple) should (and will!) be redrawn to be chiral/symmetrical to  (BS2+l_purple). -- Tuválkin ✉ 13:55, 2 November 2014 (UTC)

Beziers

Also, Useddenim, what was the idea with  (bvWSL-BS2+lxr)? YLSS (talk) 11:07, 31 October 2014 (UTC) YLSS, you mean about the naming? -- Tuválkin ✉ 20:04, 1 November 2014 (UTC) Nope, I meant Useddenim's version with a curve tilted upward. Quite the contrary of what he did with  (bvWSL-BS2+lr). YLSS (talk) 21:42, 1 November 2014 (UTC)

Axpde

While I have nothing specific to say about these icons (I do have about the larger issue, but will at some other time and place), the kind of edit warring Axpde engaged in is flatly against the rules for any issue, and indeed unworthy of an Admin. The matter should be brought to AN/U. -- Tuválkin ✉ 17:15, 31 October 2014 (UTC)

To make it clear, I reverted in my role as designer of the icon – not as an admin. And one or two reasoned reverts are not "edit warring"! a×p_de^Hello! 09:10, 1 November 2014 (UTC)

File ownership and edit warring. Like said, not good for an average user, really bad for an Admin. -- Tuválkin ✉ 10:35, 1 November 2014 (UTC)

Still not "edit warring", just reasoned reverts on files I designed! "admin" does not mean losing all rights as a user! a×p_de^Hello! 12:47, 1 November 2014 (UTC)

Authorship does not convey ownership. And just because you state a reason does not necessarily mean that it is reasoned (or reasonable). Useddenim (talk) 16:58, 1 November 2014 (UTC)

Actually, I don't understand why you concentrate on icons I only created for dewiki lacking the option of overlay. Put another way: Use overlay to get whatever look you want, but leave those icons for dewiki alone! a×p_de^Hello! 21:20, 2 November 2014 (UTC)

Ump, no chance of that! German BSicons have been most impudently appropriated by all the other Wikipedias! ;) YLSS (talk) 21:41, 2 November 2014 (UTC)

Low-res hinting and cheats

Experienced font designers know that in order to make shapes look correct at (very) small sizes, it is necessary to “cheat”: circular curves aren't, stroke thicknesses fluctuate, and letter heights vary. For example, compare  (ABZ2+4lr) and  (ABZ3+1lr) at 20px and 100px. Useddenim (talk) 00:52, 1 November 2014 (UTC)

The circles in my design are correct, no need to cheat. And the shifted line is symmetrical too, and since there is a small triangle left, it's still recognisable at 20px. a×p_de^Hello! 09:10, 1 November 2014 (UTC)

@Axpde: : you're missing the point. My redrawn version still looks nice and round, but eliminates the (IMO) unsightly “spread” as the lines diverge; there’s no necessity for the shifts to be symmetrical from top to bottom, as the icon isn’t; and at 20px, the “triangle” is only 1 pixel high, so technically, yes, it’s there, but recognizable? Useddenim (talk) 16:58, 1 November 2014 (UTC)