Request for feedback

[Michael Doub]

After more testing of list formatting, we need the listdepth and 
listindent as part of a softline because a element of a list can wrap.

Ralph, I have not used formatting within button labels, so I will have 
to research them.   I am guessing that they do not have all of the 
settings as a field.  Are they a proper subset of what is listed below 
or do we need to do the same exercise that is unique for button labels?

Here is a updated view with some line shortenings so the comments wont 
wrap within the email. (i hope)

-= Mike



put the formatedStyledAttributes of fld "foo" into rArray

rArray:
     "height":
     "width":
     "dontwrap":
     "borderwidth":
     "leftMargin":
     "topMargin":
     "rightMargin":
     "bottomMargin":
     [line_Nbr]     --    a number for each string
                         --    terminated by a return
         "borderwidth":
         "leftIndent":
         "rightIndent":
         "padding":
         "spaceAbove":
         "spaceBelow":
         [softline_number]    --    this the segment of the
                                         --    line on a row within a field
             "MaxformattedHeight":      -- of the softline including all 
runs
             "MaxformattedWidth":       -- of the softline including all 
runs
                                                        -- these are 
included to make
                                                        -- calculating 
scroll positions easier
             "leftIndent":
             "firstIndent":    --    only applicable to the first
                                     --    segment of a paragraph
             "rightIndent":
             "padding":
             "listIndent":        --    listIndent and listdepth are needed
             "listdepth":         --    as part of the softline because 
lists
                                        --    can wrap
             [run_number]       --    this is the run within the soft line
                                         --    a tab character is 
considered a run
                 "textSize":
                 "textFont":
                 "textStyle":
                 "text":
                 formattedHeight:
                 formattedWidth:     --     when text = tab, this is the 
length
                                                --    of space allocated 
to the tab
             [run_number + 1]
         [softline_number + 1]
     [pgh_Nbr + 1]


On 11/30/14 3:52 PM, Ralph DiMola wrote:
> Mike,
>
> Thanks You! I'm a + 1 on this. We need to be able to reliably calculate
> field/line geometry especially on mobile. I've been wrestling getting this
> correct since the new field object was introduced. I have 2 related bugs on
> this: http://quality.runrev.com/show_bug.cgi?id=12176 and
> http://quality.runrev.com/show_bug.cgi?id=13551
>
> It looks like you have all the bases covered. Let's see when RR and anybody
> into the sources has to offer on this. Button labels should have this
> property also.
>
> Ralph DiMola
> IT Director
> Evergreen Information Services
> rdimola at evergreeninfo.net
>
> -----Original Message-----
> From: use-livecode [mailto:use-livecode-bounces at lists.runrev.com] On Behalf
> Of Michael Doub
> Sent: Sunday, November 30, 2014 11:57 AM
> To: How To use LiveCode use LiveCode
> Subject: Request for feedback
>
> I would like the lists assistance in flushing out a enhancement request
> proposal that I would like to make to the development team. Because of a bug
> in the pageranges function where it did not take into account the spaceabove
> and spacebelow properties, i attempted to do this manually.
> I quickly learned that there is no easy way to understand where a line is
> actually wrapped.  I was using the formatted size functions measuring each
> character and run and getting different answers when measuring the same
> text.  This was attributed to kerning and letter spacing issues by the
> support folks.  This was not a very satisfying answer.
>
> After working on this for several weeks, I have come to the conclusion that
> we can not accurately reproduce the algorithms of the field object with the
> current tools available to us.  I would loved to be proven wrong here, but I
> threw in the towel and starting thinking about the the information that is
> really needed to understand what is actually being displayed within a field.
>
> I am proposing that a property or function be added to livecode field
> object.  It would be similar to styled text, but it would provide a PERFECT
> representation of what is being displayed within a field.  The structure
> returned would include all attributes needed to understand exactly how a
> field is laid out and how the text was flowed within the field.
>
> For the purposes of this discussion a field is made up of lines.
> A line is a string terminated by a return.  A line is made up of softlines.
> A line may contain a single softline or multiple softlines.
> A softline is single row of text that fits in the visual area within the
> field.  SoftLines are made up of runs as defined in styledtext.   A tab
> character is considered a run.
>
> Ok to be clear, a softline is each segment of a line that was wrapped to fit
> in to the field.  ;-)
>
>
> put the formatedStyledAttributes of fld "foo" into rArray
>
> rArray:
>       "height":
>       "width":
>       "dontwrap":
>       "borderwidth":
>       "leftMargin":
>       "topMargin":
>       "rightMargin":
>       "bottomMargin":
>       [line_Nbr] --  a number for each string terminated by a return
>           "borderwidth":
>           "leftIndent":
>           "rightIndent":
>           "padding":
>           "spaceAbove":
>           "spaceBelow":
>           [softline_number]  -- this the segment of the line on a row
> within a field
>               "MaxformattedHeight":  -- of the softline including all runs
>               "MaxformattedWidth":   -- of the softline including all runs
>               "leftIndent":
>               "firstIndent":  -- only applicable to the first segment of
> a paragraph
>               "rightIndent":
>               "padding":
>               [run_number]      -- this is the run within the soft line
>                                          -- a tab character is considered
> a run
>                   "textSize":
>                   "textFont":
>                   "textStyle":
>                   "text":
>                   formattedHeight:
>                   formattedWidth: -- when text = tab, this is the length
> of space
>                                              -- allocated to the tab
>               [run_number + 1]
>           [softline_number + 1]
>       [pgh_Nbr + 1]
>
>
> I added the MaxFormatted Height/Width so it would be easer to calculate
> the scroll positions.  A function that would tell you the softline
> number of a given chunk would also be a huge help.
>
> I look forward to hearing your comments about this proposal.   I am
> specifically looking for suggestions on how lists should be handled.
>
> Regards,
>     Mike
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>