I am very happy to say that I was proven wrong. We are able get the information needed to understand how the engine calculated the soft line wraps. If you put the formattedtext of a line that has be wrapped into a variable, the variable will contain the text of each segment of the line that was wrapped with returns inserted appropriately. Based on the number of characters in each line, you know where the line was wrapped.

-= Mike




On 11/30/14 5:01 PM, Michael Doub wrote:
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
rdim...@evergreeninfo.net

-----Original Message-----
From: use-livecode [mailto:use-livecode-boun...@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@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@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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to