Post Reply 
Matching decimal/fraction ranges
Feb. 25, 2012, 12:30 AM
Post: #1
Matching decimal/fraction ranges
I've been trying to change the main text on most sites to 13px and have found that some of them specifiy font sizes in "em" units. For example, "font-size:0.8125em"

The values that need to be changed are in a range of something like 0.75 to 1.25, but I haven't been able to match the decimal values. It seems like the example below would work but it doesn't.

Match = "font-size:[#0.75:1.25]em"
Replace = "font-size:13px"
Add Thank You Quote this message in a reply
Feb. 25, 2012, 01:37 AM (This post was last modified: Feb. 25, 2012 01:38 AM by ProxRocks.)
Post: #2
RE: Matching decimal/fraction ranges
i haven't tried it, but try swapping your "[#0.75:1.25]" for "[#0:1].[#25:75]"
Add Thank You Quote this message in a reply
Feb. 25, 2012, 09:49 AM
Post: #3
RE: Matching decimal/fraction ranges
proxo's weaknesses:
1. cannot match ranges of decimals. help and some testing implies proxo numerical range expressions must be integers.
2. numerical test "eats" leading zeroes. example: proxo sees 0005 as 5

the test value that begins 0. is easier because the remaining integers never lead with 0

this expression seems to work
add diagnostic LOG()
these tests succeed:
0.0005 no match
0.7005 no match
0.7000 no match
0.7499 no match
0.75 75:99
0.7500 7500:9999
0.9999 7500:9999

we might prefer this match, but it needs extending the match expression to another digit
0.99990 no match

I'm going to try to make the other messier values match expression...
then 4 more digits, values 0 through 25
Add Thank You Quote this message in a reply
Feb. 25, 2012, 04:49 PM
Post: #4
RE: Matching decimal/fraction ranges
the rabbit hole got deeper and deeper... after hours, my brain lost concentration. (also causing clumsy sentence structure in this post)

An idea:
if you usually leave browser Javascript enabled, javascript should do math very conveniently (but I don't know js). otherwise this is as far as i followed the rabbit holes. And maybe the test examples are useful.

My previous reply is the 0.nnnn case. i actually tested the expression in the Bounds with only * in Match.

above includes small edit, for when real world css might omit leading 0
example .8888 match by .nnnn

0.nnnn case seems ok.

same testing of the 1.nnnn case.
1(.(([#0:1001]$LOG(C#0:1 )|2$LOG(C2 )([#0:401]$LOG(C#0:4 )|5$LOG(C5 )([#0:*]$LOG(C#0:* )|$LOG(Cnothing ))))|[#0:*]|)|[#0:*]|)

This filter tests only the 1.nnnn case
Name = "FontReSizeCss[sbk20120225T2a 1.nnn was1c"
Active = TRUE
Multi = TRUE
Limit = 24
Match = "([^0-1]+)\1"
        "1(.(([#0:1001]$LOG(C#0:1 )|2$LOG(C2 )([#0:401]$LOG(C#0:4 )|5$LOG(C5 )([#0:*]$LOG(C#0:* )|$LOG(Cnothing ))))|[#0:*]|)|[#0:*]|)"
Replace = "\113px"

examples of possible css numerical variations.
1.2501 2 5 #0:*
1.24 #0:1
1.2400001 2
1.249 #0:1
1.2499 2
1.24999 2

1 yes
1. yes
1.0 #0:1
1.000 #0:1
1.0000 #0:1
1.00000 #0:1
1.00009 #0:1
1.0009 #0:1
2 [No Match]
2. [No Match]
2.0 [No Match]
3 [No Match]

I tested bounds expression alone, in Bounds. (use only an * in Match)

Then assembled bounds, 1.nnnn, and 0.nnnn
Name = "FontReSizeCss[sbk20120225T1c"
Active = FALSE
Multi = TRUE
Bounds = "font-size: ([0]+.[7-9]|[#1](.([0-2]|)|))*++ em"
Limit = 24
Match = "([^0-1]+)\1("
        "1(.(([#0:1001]$LOG(C#0:1 )|2$LOG(C2 )([#0:401]$LOG(C#0:4 )|5$LOG(C5 )([#0:*]$LOG(C#0:* )|$LOG(Cnothing ))))|[#0:*]|)|[#0:*]|)"
Replace = "\113px"

Then i found a problem. i hadn't earlier tried this numerical example, which the assembled filter fails to reject:
used this to test the assembled filter:
font-size:1.999 em

I then tested example with only Bounds and with only 1.nnnn
They also fail to reject.

My suspicion:
sub expressions were intended to eat excess trailing digits.
But i think these subexpression(s) have too much freedom.
For the fail example font-size:1.999 em
the [#0:*] allow the overall Match to act like
or act like

i think those trailing digit subexpressions
need to be moved to inside some OR cases, so the [#0:*] cannot eat trailing digits of some examples, which would cause filter to reject.

i think the Bounds has similar problem. It eats trailing digits for too many examples. This would be the part:
|)|))*++ em
and for the same example 1.999

Sometimes I thought treating digits as characters [0-4] would be better than treating digits as numerical ranges [#0:4] But I think variations of few or many digits would cause same difficulty to match . Some examples:

i think all of this demonstrates how easy to get into a mess. Sad
Add Thank You Quote this message in a reply
Feb. 25, 2012, 05:34 PM
Post: #5
RE: Matching decimal/fraction ranges
preliminary completely different approach.

(except a similar Bounds to filter only when beginning characters are only 0. . 1 1. )

the main part of filter might be able to
find number of the digits and location of dot.


remove dot.


test with different numerical range, depending on original number of digits:
0nnnn, nnnn, 1nnnn [#7500:12500]
0nnn, nnn, 1nnn [#750:1250]
0nn, nn, 1nn [#75:125]
0n, n, 1n [#8:12]
1 [#1]
Add Thank You Quote this message in a reply
Feb. 25, 2012, 10:16 PM
Post: #6
RE: Matching decimal/fraction ranges
Problem with [#m:m] is that it requires integers.
Problem with decimals is that .3 is larger than .200

Try something like

Name = "Test 0.75 to 1.25 to 13px"
Active = FALSE
Limit = 256
Match = "font-size:("
        "1.+) em"
Replace = "font-size:13px"

Add Thank You Quote this message in a reply
Feb. 26, 2012, 03:40 AM
Post: #7
RE: Matching decimal/fraction ranges
JJoe, thank you, that one works perfectly with all my test examples so far, even ones without the leading "0".
I may have to adjust the range a bit, depending on results, but it seems pretty simple to tweak.

sbk, I appreciate all the testing, although parts of the rabbit hole did get a bit too deep for me to follow.
Add Thank You Quote this message in a reply
Post Reply 

Forum Jump: