Writer manually search on attribute charHeight when in style paragraph value is percentage

[torreone]

I have a paragraph writer style D derived from a main style M
In the M style the font size is set to 10pt, in the derived style D the fontsize is set to 105% (10.5pt)
In the search tab (activated by CTRL + H) selecting font size as attribute there are two problems

1. in the format tab, percentage values ​​are not accepted, which is possible in the definition of the paragraph style
   Only pt values ​​are accepted.
2. trying to set 10.5pt as the comparison format in the format tab (exactly the value returned by the UNO object Inspector as CharHeight property of the paragraphs formatted with style D) nothing is found

On the contrary, setting in the style D fontsize = 10,5 instead of the old 105% the search works very well

The associated UNO property is CharHeigth, of type float / single.
I tried running the same search with a macro, getting the same results.

Is this normal?

Libreoffice 7.3.5.2 ubuntu 16.04

[ajlittoz]

IMHO, your procedure is faulty. Find & Replace has interest only if your text is direct formatting since these attributes are not defined in a style.

You should consider there are two antagonist ways to format a document: styling vs. direct formatting. They must not be mixed unless you appreciate the resulting “formatting hell”.

Consequently, if your goal is to find the paragraphs under style D, then search for paragraph style D. If you’re looking for direct formatting, yes, look for 10.5 pt.

The reason why 105% font size does not work in Find & Replace is simple: every relative size is converted to absolute size before being used. The conversion needs a reference. In the case of a derived paragraph style, the reference is the ancestor style, main M in your example. Were it possible to enter relative sizes in F&R, what would be the reference? You’re outside styling, there is no unquestionable reference. Ambiguity is at its maximum.

LO self-defence is to forbid relative entry.

To summarise:

• in styling context, customise styles; F&R is of no use to look for style parameters
  F&R could be used to search for direct formatting if you suspect there is some but it is faster to select an area and Ctl+M and see if something changes or use the style inspector in the side pane
• in direct formatting context, relative sizes are nonsense because you have no reference
  Direct formatting is independent of any other formatting

[torreone]

Your explanation as to why relative measures are not allowed as comparison terms is compelling
I understand less the logic of considering searching by attributes only as a function of direct styling.
In this case I don’t understand why there is the “include style” checkbox with its “searchStyles” property in the search descriptor that allows very complex and very fast searches working on the combination of attributes
In my case I am, little by little, trying to eliminate direct formatting as much as possible by working on styles not only in terms of efficiency in editing formats but, above all, in defining styles and related attributes to quickly select different areas of the document. according to the information content (e.g. definitions, insights, headings, examples, exercises, etc.)

[ajlittoz]

@torreone

I don’t understand why there is the “include style” checkbox

Well, I just checked now. It works but depending on the attribute it may be very tricky because the GUI doesn’t always tell you visually what is selected and what isn’t. This is the same problem as with style definition. When you enter configuration tabs you initially see what is set in the ancestor but later you can’t tell for sure what you set because display is binary while attributes are tri-state: “transparent” (= inherit from the ancestor), set and unset (the last two are forcing values, overriding ancestor). In the case of size, it is even more complicated.

After my test, I couldn’t reset F&R to “neutral” (the italic criterion in Format couldn’t be erased; if I click on No Italic, I get the opposite of Italic, not a neutral ignored criteria; the only way is to close Writer and relaunch – not user-friendly).

That’s why I think F&R is rather targeted at direct formatting. Once you’re fully styled, use it only to locate used style locations but there are probably better ways.

[torreone]

Thanks for sharing your test results, I didn’t take into account the binary-tristate difference, for example
As always, it is a cost-benefit balance. In my case, I only produce documents for my personal use, so with maximum freedom of formatting.
Furthermore, I always work on two parallel planes, use manual gui and automation with starbasic even at an in-depth level.
Working with parameterized search functions and with well-constructed styles, it is possible, for example, to select at the same time all the headings of a document (just one common attribute is enough, for example the fontfamily) or only some subsets (e.g. only headings 1-2-3) combining two attributes.
And if you want, you can combine styles with the logical or operator with small runtime modifications of the style attributes.
The paragraph style search, on the other hand, obtains only one heading at a time.
Or you can quickly extract all the text blocks associated with definitions, if their charbackcolor or charcolor or fontfamily is unique in the document.
writer unlike calc does not allow you to add a textrange to a pre-existing textranges (or rather, in the case of texts with only paragraphs it can but is very complicated)
Being able to directly select the required textranges with a single search operation is very important, especially if you work with generalized functions parameterized on the type of information to be found.
It is a technique that greatly reduces the code to be created

It should be added that the search in the selection is only possible with dispatch, strangely this option has never been supported by the search descriptors.
I have already experienced that some attributes give problems (eg CharTransparence), but others also work very well in combination, at least from the first tests I ran.
The advantages, for now, outweigh the disadvantages
I’ll keep you up-to-date.

[torreone]

I don’t know if it is appropriate to open another discussion, I just encountered a problem that seems to be related to this one.
When directly or styled the fontsize of a character is not an integer (e.g. 10.1, 10.2, 10.3, 10.4, 10.5pt) in the definition window (style or character properties) the definition remains stable (e.g. defining 10.2 I find myself in followed 10.2)
But verifying the value of the CharHeight property from a macro or UNO object inspect the actual value may be different (e.g. 10.15 instead of 10.2)
Furthermore, trying several times in the same textRange to modify the CharHeight with different values, all not integers, it is absolutely not certain that the same value accepted correctly before (e.g. 10.2) will be accepted correctly even after a subsequent new application
And here we are not talking about relative values, but about absolute values, albeit not integers
Only the approximation to 0.5 seems stable (e.g. format cherheight at 10.5 and that value is found at each subsequent subsequent formatting with 10.5
In the past I had not noticed it because I had not verified the actual value by trusting the theoretical value set in the definition sheet
I checked this with two different fontStyle, freesans and liberationserif

[ajlittoz]

I think this is related to the internal integer representation of height. All measurements are a multiple of a basic unit (I don’t remember if this is 1/100 mm or 1/200 mm, but at this stage it doesn’t really matter). A point is defined as 1/72 " and one inch is 25.4 mm. 1pt is therefore ~0.353mm and 0.1pt ~0.035 mm. You see it falls between 3 and 4 basic units. Therefore, depending on conversion rounding, you may observe some dispersion.
10.15pt ~ 3.58 mm (assuming there is no conversion error from string 10.15 to internal corresponding number)
10.2 pt ~ 3.59 or 3.60 mm (depending on how computation is done)
The difference is on the order of 1 basic unit. You can’t get a better approximation.

Don’t rely on tiny size differences. Anyway, you’ll get different results on screen and on paper due to the difference of pixel density in both media.

[torreone]

Very thanks! (All measurements are multiple of 1/100mm)
The problem is always related to the search for attributes and seems to be more in the process of being solved. .
I am trying to attribute whose format, once assigned, is stable (ie, whenever I assign 10.2 the format of the attribute must be 10.2)
In the search by attributes it is not possible to grant a range of allowed values, the attribute value must be unique and then must be stable, not random
From the tests I am currently carrying out, apparently “stable” attributes are fontfamily, color, background (of paragraph and character), the paragraph margins (top-bottom-right-left, at minimum multiples of 0.1cm) and the firstlineindent (minimum multiples of 0.1cm)
The fontsize seems to be safe to use only in multiples of 0.5pt
Strange, however, that it gives me different results by applying the same value (eg 10.2) at different times. The calculation algorithm should be the same and therefore the final result as well.
In my case these stable attributes searched in combination (maximum 2 or 3 per search) allow me to filter the headings automatically in many different ways (e.g. H1-H10, or H1-H6, or H1-H5, or just H1 and H2, or H3-H4-H5-H6, or H3-H4-H5, or H7-H10, etc, this was the ultimate goal

[ajlittoz]

For heading filtering, have looked at the Navigator in the side pane. It will not select but you can navigate very quickly to a specific heading.
Doesn’t FindAll work when you search for Heading 1 (or another level) paragraph style?

[torreone]

If you are referring to searching for paragraph styles, searching for heading 1 (like heading x) will only find the headings of that level, not the others or subsets of them.
Working instead on the style attributes of each heading, defining attribute values ​​common to subset of heading, I see that it is possible to select with a single operation (obviously with macros, but that has always been my aim) almost all possible combinations of subset of headings (and in the future of any type of information that can be associated with styles)
I really like the navigator from version 7 onwards, but it does not lend itself to automation because it does not allow macros to share, at least in reading, all the pointers to the headings that the navigator certainly has.