[reportlab-users] underline and strike parameters (and link regions)

Robin Becker robin at reportlab.com
Wed Mar 21 05:28:34 EDT 2018


On 20/03/2018 18:58, Glenn Linderman wrote:
..........
>> I know how to implement b, but I haven't got any idea how to indicate it; I would prefer we use only one local property position 
>> so either at the tag or when the tag gets first used, but others may disagree.
> 
> I think ^ = d should be d = ^ ?? Or the chart is confusing.  I think ^ is a poor choice for a tag, would prefer alpha, such as  L 
> (for line; uppercase, because F for para is uppercase, and both are concepts larger than local).
> 
yes my bad


> c) seems more appropriate than b) so that order of <u> and <span> is less important. I'm surprised your example doesn't conform to 
> nesting requirements for <u> and <span>, though.
> 
> And, you've missed one concept: †) maximum fontsize for the range of the underline, which to me makes more sense than either b) or 
> c).
> 

No I have already implemented that for link regions except there we have to account for super/subscripts etc etc, but you are 
right there is another option.

> And maybe another, if the range of the underline is multiple lines, maybe ‡) maximum fontsize for the range of the underline on 
> each line. So it could vary based on actual usage on each line.
> 
>> 3) The color of lines may either be absolute eg red or perhaps indicated by some special notation to use a default mechanism. 
>> Currently we assume that the  line color will be the same as the text colour of the first drawing. There are probably three 
>> sensible relative defaults which could be adopted.
>>
>>     e) paragraph level text color
>>     f) textColor at the point of definition
>>     g) textColor at the point of first use.
> 
> Another missed option: *) same color as text being underlined, which means the underline may change colors along its length

I ignored this possibility, if you really want multiple lines then we will allowing multiple levels of underline/strike etc etc.


..........
> I'm not sure where you are talking about putting the suffices for font size either; not on the text font size, so where? An 
> example of usage would have been nice.  I'd suggest
> 
> <u ufontsize="code">
> 
> code would be one of the "which text size should I track" options, or an explicit font size.  Likewise for underline color...
> 
> <u ucolor="code">
> 
> where code could be a color, or a special designation for these various options of text color tracking. ucolor could be spelled 
> lots of ways, but not conflicting with HTML attributes would be good. Using the well-defined user attribute naming such as 
> data_fontsize and data_color might be better.
> 
>>
> 
no the various text properties would only be used in default cases so my current implementation has

<u width="code_s" offset="code_o" color="code_c">....
<strike width="code_s" offset="code_o" color="code_c">...
<link uwidth="code_s" uoffset="code_o" ucolor="code_c" underline=<bool>...> ....

the code_i would be where special or absolute values go. So for example width=<num><special suffix>  would indicate a calculated 
value based on some font size eg 0.05F or 0.05MAX or whatever we decide to use; 0.5pt would mean an absolute value.

To sum up we seem to have code requirements for

    a) paragraph level fontSize normally set by the style parameter so 10
    b) local fontSize at the point where the tag appears 11.
    c) local fontSize at the point where the underline first gets drawn so 12
    d) the maximum font size over the line ie 14
    k) maximum font size over the tag (harder to compute).

    e) paragraph level text color
    f) textColor at the point of definition.
    g) textColor at the point of first use.

clearly the codes must be something that doesn't clash with the corresponding absolutes; 'para' or 'line' could be easily 
confusable with 'red' (just define a color called 'line' etc etc); single character. I have implementations for a, c, d and am 
using g.
-- 
Robin Becker


More information about the reportlab-users mailing list