Is applying (retaining?) conditional numerical value-based field formatting after applying fieldformat that normalizes the values - an option? (It appears not?)
Hope it's clear why neither option is satisfactory: fields with fieldformat applied - are left justified and with no (numerical) value-based conditional formatting making it counter-intuitive and generally unreadable. Fields w/o fieldformat: can quickly and irrevocably get unreadable as they can easily get into petabytes depending on the search timeframe and how busy the application has been.
For comparison, this is from a much younger competing product enabling auto formatting and normalizing data in ways that appear to be missing in Splunk:
printf can't right-justify a string, correct? So printf isn't applicable here?
(Sure, tostring's output may stay right-justified - yet conditional color formatting? Gone.)
The use case in my question, to make both large and small numbers readable in the same table using unit prefixes (aka multipliers like "kilo", "mega", etc.)? Dead in the water. Yet arguably this is Splunk's #1 job: "make data actionable" - which can't be done w/o making data readable.
Splunk does a fairly decent job with conditional color formatting on numerals in a table - I don't see similar options in the competing product I mentioned in my OP.
Yet losing those formatting options the moment I try to make those numerals readable beyond what's available in column formatting? Find it hard to fathom.
P.S. I get the part about formatting strings vs. numerals - it's all over Splunk Answers including in the answer I've linked to in my OP. Perhaps it's too much to ask for Splunk to do conditional formatting based on raw values rather than formatted ones. Yet at least give me an option to right-justify a string w/o going to a CSS? Better yet, add unit prefixes to conditional formatting options?
