User talk:Ineuw/T1

Struck out

		   (default font-size:100%, line-height:140%;)
		   {{#ifexpr:(100>{{{1}}})|line-height:normal|}}
		   {{#ifexpr:(100<={{{1}}}) and ({{{1}}}>=94)|line-height:140%;|line-height:140%;}}

* {{User:Ineuw/TT|100}}
* {{User:Ineuw/TT|99}}
* {{User:Ineuw/TT|98}}
* {{User:Ineuw/TT|97}}
* {{User:Ineuw/TT|96}}
* {{User:Ineuw/TT|95}}
* {{User:Ineuw/TT|94}}
* {{User:Ineuw/TT|93}}
* {{User:Ineuw/TT|92}}
* {{User:Ineuw/TT|91}}
* {{User:Ineuw/TT|90}}

results in....

<ul>
<li><span style="display:inline-block; font-size:100%;line-height:130%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:99%;line-height:130%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:98%;line-height:130%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:97%;line-height:130%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:96%;line-height:130%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:95%;line-height:130%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:94%;line-height:130%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:93%;line-height:130%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:92%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:91%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
<li><span style="display:inline-block; font-size:90%;line-height:120%;line-height:110%;line-height:100%;">{{{2}}}</span></li>
</ul>

that's not so good @Ineuw:. You can't have ... or equal to on both sides of the AND I'm guessing. -- George Orwell III (talk) 19:07, 25 June 2015 (UTC)

Might need to reverse the queries by going from the lowest number for an input up to the max (100) instead of 100 on down ? -- George Orwell III (talk) 19:10, 25 June 2015 (UTC)

May I suggest a complete rethink along the lines of replacing the fragment:

--><span style="display:inline-block; font-size:{{{1|100}}}%;<!-- -->{{#ifexpr:(93<={{{1}}}) and ({{{1}}}>=88)|line-height:130%;|}}<!-- -->{{#ifexpr:(87<={{{1}}}) and ({{{1}}}>=84)|line-height:120%;|}}<!-- -->{{#ifexpr:(83<={{{1}}}) and ({{{1}}}>=78)|line-height:110%;|}}<!-- -->{{#ifexpr:(77<={{{1}}}) and ({{{1}}}>=74)|line-height:100%;|}}<!-- -->"><!-- -->{{{2}}}<!-- --></span><!--

with:

--><span style="display:inline-block; font-size:{{{1|100}}}%;<!-- -->{{#if:{{{1|}}}|<!-- only perform ifexpr:s if {{{1}}} is set -->{{#ifexpr:({{{1}}}>=88)|line-height:130%;|<!-- -->{{#ifexpr:({{{1}}}>=84)|line-height:120%;|<!-- -->{{#ifexpr:({{{1}}}>=78)|line-height:110%;|<!-- -->{{#ifexpr:({{{1}}}>=74)|line-height:100%;|<!-- -->line-height:75%;<!-- case where: {{{1}}} < 74 -->}}<!-- end of case: {{{1}}} >= 74 -->}}<!-- end of case: {{{1}}} >= 78 -->}}<!-- end of case: {{{1}}} >= 84 -->}}<!-- end of case: {{{1}}} >= 88 Case: {{{1}}} is empty/unset -->|line-height:normal;}}<!-- -->"><!-- -->{{{2}}}<!-- --></span><!--

? AuFCL (talk) 23:06, 25 June 2015 (UTC)

Comments.

@George Orwell III: please check out this page for the results so far. User:Ineuw/Sandbox2 — Ineuw talk 23:40, 25 June 2015 (UTC)

Check it out now

@George Orwell III: and @AuFCL: please check out the both the template and the results. Our motto=[Template by the Three stooges]— Ineuw talk 02:00, 26 June 2015 (UTC)

Always happy to be one of the clowns. All fun, no responsibility and the Ringmaster is always there to take the blame when the public wants their money back. Compared with the downside a trouser-load of whitewash is a bargain. AuFCL (talk) 05:10, 26 June 2015 (UTC)

Now to be Serious

The Problem

I've read your email and had a bit of a look at the evidence and usage. Correct me if I am wrong but it looks like you want a drop-in replacement for {{fsx}} (i.e. maintains the quirks of that particular template) but "automatically" varies the lh of {{fsx}}; instead of defaulting to 1.5em, instead obeying this rule (please fill in the question marks!):

Input ({{{1}}})	Output font-size	Output line-height
200	200%	default
150	150%	default
120	120%	default
100	100%	140%
90	90%	130%
85	85%	110%
75	75%	100%
empty/omitted	?	?
1.5em	?	?
40px	?	?
70%	?	?

Tentative Solution

• Generating font-size is apparently easy: just use the input value.
• line-height should not be generated at all for inputs >100.

• Otherwise generate line-height from 'your' rules i.e.:

		input	<=	75	→ 100%
75	<	input	<=	85	→ 110%
85	<	input	<=	90	→ 130%
90	<	input	<=	100	→ 140%

Even more tentative Code (implementing above)

	--><span style="display:inline-block; font-size:{{{1|100}}}%;<!--

 		-->{{#if:{{{1|}}}|<!-- only perform ifexpr:s if {{{1}}} is set

 			-->{{#ifexpr:{{{1}}}<=100|<!--

				-->{{#ifexpr:{{{1}}}>90|line-height:140%;|<!-- i.e. 90 < {{{1}}} < 100

					-->{{#ifexpr:{{{1}}}>85|line-height:130%;|<!-- i.e. 85 < {{{1}}} < 90

						-->{{#ifexpr:{{{1}}}>75|line-height:110%;|<!-- i.e. 75 < {{{1}}} < 85
							-->line-height:100%;<!-- i.e. {{{1}}} <= 75

						-->}}<!-- end of case: 75 < {{{1}}} < 85

					-->}}<!-- end of case: 85 < {{{1}}} < 90

				-->}}<!-- end of case: 90 < {{{1}}} < 100

			-->|}}<!-- end of case: {{{1}}} <= 100

		Case: {{{1}}} is empty/unset (action not yet determined)
		-->|}}<!--

	-->"><!--

		-->{{{2}}}<!--

	--></span><!--

"Real" Demonstration (see /demo)

input	F(input)
70	style="display:inline-block; font-size:70%;line-height:100%;
71	style="display:inline-block; font-size:71%;line-height:100%;
75	style="display:inline-block; font-size:75%;line-height:100%;
85	style="display:inline-block; font-size:85%;line-height:110%;
90	style="display:inline-block; font-size:90%;line-height:130%;
100	style="display:inline-block; font-size:100%;line-height:140%;
120	style="display:inline-block; font-size:120%;
150	style="display:inline-block; font-size:150%;
200	style="display:inline-block; font-size:200%;

Outstanding Issues

• What to do if the first parameter is omitted or contains a unit selector (%/em/px &c.)?

  Should an attempt be made to strip and preserve the unit, recalculate values and then re-append said unit to the result before applying it to style? (e.g. should an input value of "70%" generate output "font-size:70%;line-height:95%;", and input value of "70px" generate output "font-size:70px;line-height:95px;"?

The history

@AuFCL: First thanks for your time. The history of this issue is that "fsx" is still used ~2,737 out of ~3,000 times in the PSM pages, mostly for single row titles. But when it came to be used on paragraphs with several rows, the inherited line height was of the 100% font size, and comparing this to printed text it was not nice (for lack of a better word).

To correct this, I created {{fs90}}, {{fs85}}, and {{fs75}} but with a big mistake. They are enclosed in <div> and not in <span> which makes them useless for inline use. {{fs90/s}} . . . etc. By User:AdamBMorgan resolved the issue of spanning paragraphs and pages but it's still enclosed in <div>

• To answer you questions posed at the beginning of this and the previous posts, "Yes", would like the same functionality as the orginial fsx template - that it should accept "em", "px", "%", but NO word definitions like "smaller" etc.

• As for the range of line heights, greater than 97% should be the default line height (140%) or whatever it is in other measurement or look at this table as a guide: 100% and smaller font size and style comparisons table.

• The "140%" as the line height of font-size:100% came from my very archaic method of calculation, made several years ago when I knew even less, but Inductiveload confirmed it. From then on I used that as the basis since I never used anything else with this template other than "%", but other may have.

The plan

• When its done, I will make a proposal in the Scriptorium, and if the community accepts the proportional line height of this new fsx code, then this would solve my replacing fsx templates with fs90, fs85 etc.

• I checked "fsx" use in other book/projects and it's used for font sizes larger than 100% in titles, but didn't come across its use for smaller font sizes.

• Finally, if the community does not accept it, I'll keep using my fs90 etc., templates, and explore replacing the <div> with <span>.

If you have any more questions, I will gladly reply, most likely in a very long winded way. — Ineuw talk 20:08, 26 June 2015 (UTC)

"most likely in a very long winded way": I deserved that as my 'question' was even longer.

I forgot to highlight this earlier but an implication of handling that compatibility issue with fsx (and more specifically units appearing alongside the numeric size) pretty much forces the abandonment of all your experimentation with template wikicode in preference to re-implementing {{Font-size-x}} in LUA. Maybe that (looking ahead to look back) might be your eventual Scriptorium justification? And unless you already know the language I am sure you will find the exercise … diverting. AuFCL (talk) 22:26, 26 June 2015 (UTC)

Please don't go to the trouble of LUA for sure! Just let the sleeping dogs sleep and dream. I have enough templates as it is. I check the pages where a template is used, an image is placed, and also must anchor contents. — Ineuw talk 03:44, 27 June 2015 (UTC)

A man surrounded by his dreaming, sleeping dogs; with enough templates to satisfy his every need? You must be very contented indeed. And how many enemies are tied to those anchors awaiting the arrival of the incoming tide? (Don't answer that!) AuFCL (talk) 04:23, 27 June 2015 (UTC)

You made my day. Very funny. Now I can go to sleep. Thanks for everything.— Ineuw talk 07:13, 27 June 2015 (UTC)

Success of sorts

Promise that this my last ping of the evening @George Orwell III: and @AuFCL:. Your comments are appreciated (the cheque is in the mail).

I tweaked the template a bit and the last paragraph of this page where there is no fs and lh specifications, is identical to the paragraph where 100% font size is specified, (font-size:14px and line-height: 22.4px). And both are the same as the current Wikisource standards. P.S: There is no font-size, or line-height in my css, but will log out to be sure. — Ineuw talk 07:11, 28 June 2015 (UTC) P.S. Logged out and the specs are the same.— Ineuw talk 07:12, 28 June 2015 (UTC)

I fixed a couple of minor issues in the template (some human-readable internal comments were being leaked into the generated HTML.) However, the behaviour you drew attention to (100% generating standard values) is precisely what I would expect 100% (===factor 1) ought to do. If this really is a problem tell me what you want and I can probably show you where to change it. (In other words I really do not understand what your expectations are?) AuFCL (talk) 07:38, 28 June 2015 (UTC)

Thanks for the corrections. First, need to make some additional tests with the old fsx and then I'll get back to you. . A question, what editor are you using for this template and .js in general? — Ineuw talk 08:05, 28 June 2015 (UTC)

Editor for these corrections? Simply the mediawiki text-editing panel. Largely the same for Javascript (I have a soft spot for EMACs for local/offline work—the old kitchen sink rarely lets me down. Don't get me started on the editor wars: I've probablydinner/news used every single one newer than TECO at some stage.) AuFCL (talk) 08:11, 28 June 2015 (UTC)

But the text had tabs in it how can one insert tabs in to the text here?

Also I believe that some end cases are missing the commenting out. I copied out this segment.

                        -->}}<!-- end of case: {{{1}}} >= 74

                    -->}}<!-- end of case: {{{1}}} >= 78

                -->}}<!-- end of case: {{{1}}} >= 84

            -->}}<!-- end of case: {{{1}}} >= 88<!-- should this be here?

        -->}}<!-- end of case: {{{1}}} >= 94

— Ineuw talk 08:17, 28 June 2015 (UTC)

Pardon slow response: dinner/news.

The tabs were already present in the initial version of the template (GO_III?) I merely tried to preserve them by cutting and pasting.

Short answer: NO. That comment-start at the end of the "88" line just happens to already be inside the comment-start immediately following the double-closed braces. In essence COMMENT-start COMMENT-start COMMENT-end just happens to work as a solid comment block but might not work in every browser. AuFCL (talk) 09:30, 28 June 2015 (UTC)

My turn to ask you a question: Why is the ">=94" case being tested for, as the corresponding action is to do nothing? I would have thought that was the old "line-height:140%;" case? AuFCL (talk) 09:41, 28 June 2015 (UTC)

A much later response. I was delayed by the stupid habit of indulging in a few hours of sleep.

To answer the last first - I am changing the size ranges to be based FROM THIS TABLE because when I created the table, 94% was where the size change was noticeable. It's probably because I had a 17" CRT and now I use a 22" LED. Another noticeable difference (to me) is that the mediawiki image resolution has since markedly improved. What didn't change is the line height. 140% is still the same until 100% font size, but beyond that I won't guess and is not important because the font size/line height proportion are not important. The new ranges are 97%, 90%, 83%, 75%, and 68%.)

The problem with copying and pasting of tabs was that everything began to shift around, I made a big mess, some code at the end disappeared (but recovered). So quickly created a keyboard macro with AutoHotkey which generates four spaces.

Testing fsx em, points, & mm

{{font-size-x}}

fsx|1em = fs - 14px + lh = 21px

a fair ground for the expectation that the whole cosmic process will turn out to be one of evolution. The business of philosophy, as I understand it, is, among other things, to arrive at a scientific theory of evolution; but these other things are quite as important as evolution. Philosophy, in fact, should embrace the whole of which the theory of evolution is a part.

fsx|10.5pt - fs = 14px + lh = 21px

a fair ground for the expectation that the whole cosmic process will turn out to be one of evolution. The business of philosophy, as I understand it, is, among other things, to arrive at a scientific theory of evolution; but these other things are quite as important as evolution. Philosophy, in fact, should embrace the whole of which the theory of evolution is a part.

fsx|3.7mm - fs = 13.9833px + lh = 20.98px

a fair ground for the expectation that the whole cosmic process will turn out to be one of evolution. The business of philosophy, as I understand it, is, among other things, to arrive at a scientific theory of evolution; but these other things are quite as important as evolution. Philosophy, in fact, should embrace the whole of which the theory of evolution is a part.

A possible simplification?

@Ineuw: Whilst I am sure you are heartily sick of this topic please bear with me for one last suggestion. Rather than have all those tests for various font-size factors each of which generating individual line-height multipliers (for convenience reproduced below—including a couple of fudge-factors):

Figures extracted from latest version of {{User:Ineuw/T1}}

font-size:	line-height:	Notes	Calculated (see below)
97	140%	unstated but accepted default	140.65%
90	130%		130.5%
83	120%		120.35%
75	110%		108.75%
68	100%		98.6%
50	68%	My estimate from context	72.5%

Now indulge me for a moment. The geometric mean line-height works out to be about 108%, and for font-size: 75%. The ratio of these g.m.s is thus 1.45.

Now what if we replace all those tests with the code from {{User:Ineuw/T2}}, modified instead to calculate line-height as a simple product of the above ratio and the font-size (for the moment I'm assuming {{{1}}} is a percentage but lacking the actual "%" unit-specifier—something to fix up later if this idea proves to have merit. I have also placed this code in User:Ineuw/T3):

<includeonly><!--
--><span <!--

-->style="<!--

    Support multi-line enclosures (without this line line-height fails to propagate over line-wrap):

        -->display:inline-block;<!--

            The basic resizing factor:

            -->font-size:{{{1|100}}}%;<!--

                Allow for custom line-spacing (default probably O.K. most cases):

            -->line-height:{{#expr:{{{1|100}}}*1.45}}%;<!--

        End styling:

    -->"><!--

Inline content to be resized:

        -->{{{2}}}<!--

--></span><!--

--></includeonly><noinclude><!--
{{documentation}}
--></noinclude>

The table from here was moved to User:Ineuw/Sandbox3

Well, what do you think? AuFCL (talk) 03:54, 1 July 2015 (UTC)

First, my thanks for your time, but also knew that we wouldn't rest. Myself, feel like the chicken sitting on eggs that refuse to hatch. "It's in the nature of the beast" as they say, whoever "they" are.

Unfortunately both the font sizes and the line heights are way out of whack. We must use the 100% font size as a standard, which does not match the standard line height of 22.40px of the Wikimedia code behind Wikisource, and therefore it would be rejected by the community and I would agree.

The {{User:Ineuw/T1}} would not be acceptable because it is restricted to %, and {{User:Ineuw/T2}}, which is identical to {{font-size-x}} except the line height was changed by from a fixed height to a scalable one would also be rejected.

In either case (T2 and T3) the font sizes and the line heights over 100% are not natural progressions.

These are the reasons why I suspended the project for the time being, until we can come up with something better. — Ineuw talk 04:39, 1 July 2015 (UTC)

Well I did effectively promise no more. Even if my only achievement is to plant the idea that a single function might serve for multiple internal independent fixed parameter values I shall call my mission a partial success. AuFCL (talk) 05:13, 1 July 2015 (UTC)

2015-07-02

Getting back to the "out of whack" point and as to what looms over the horizon in the future for us typography wise, most indicators infer (at the minimum) another change to Vector's current defaults (14.0 & 22.4) will be thrust upon us sooner than we think. Again, I urge you to look to the current settings found when viewing pages in Mobile Mode as the "norm" to go by if you/we decide to move forward with this or any other lofas-like endeavors. So "fixing" or "tweaking" either the current .css file-based definitions or any existing inline template settings might not worth the trouble in the end in light of that seemingly certain typography change (a la Winter project slash Visual Editor) to come. -- George Orwell III (talk) 02:33, 2 July 2015 (UTC)

On top of all that I do not feel our mutual friend has quite grasped the concept he is trying to emulate a second-(or worse: possibly higher-)order effect using linear methods. Doomed to failure on so many levels. AuFCL (talk) 03:18, 2 July 2015 (UTC)

Surprised as you may be I am beginning to understand the issues. I just play with these to understand more because I am a WYSIWYG person. GO3 Thanks for mentioning to focus on the mobile mode. In fact I am looking for a smartphone to buy. Want/need a GPS + WiFi + good built in camera, the phone is unimportant. Ha ha. — Ineuw talk 17:41, 2 July 2015 (UTC)

Please understand, just because harsh language is being used, does not mean the user(of said language)'s intent is unkind. I understand the arguments and motivations, just not always if the relevant message is being received. All of us have strengths and fallibilities, and friends know (but care not) exactly where the bodies are buried… (Now your turn to burn me where appropriate!) AuFCL (talk)

No harsh language was used, I don't know where you got that? I appreciate all written information and that's kindness, because it helps me to understand something that I have been avoiding. — Ineuw talk 13:34, 3 July 2015 (UTC)