If you convert XML to string READ THIS!!!

[Joel Marks]

I want to make everyone aware of a bug that Adobe is saying is in Chrome.
If you use xml.toXMLString() or xml.toString() or String(xml) there is a
possibility that your xml is going to be clipped for users that are on 32
bit Chrome on Windows.

If you want more information you can refer to the Chrome bug ticket
 we have
created.

After looping 5000 times over xml that has 100 nodes with 100 attributes of
130 characters it failed 190 times and every time passed after doing
another .toXMLString()

Here  is how we are
fixing it (Spoiler: We just retry)

Re: Pasting behavior in TLF

[Joel Marks]

Sorry for not replying earlier. I only check this mailing list about once a
month or so.

We rolled our own RTF parsing solution and it sucked. RTF sucks in general.
I would suggest what we are doing with our new text editor written in Dart
and just use HTML. TLF doesn't include a parser for that either but it is
much easier to develop than RTF and HTML includes all the information you
need. Word even goes as far as including advanced features like footnotes
in the HTML that it puts on the clipboard.

On Mon, Jun 1, 2015 at 8:32 AM, Harbs  wrote:

> I’m working on some issues related to pasting text in TLF and I’m not sure
> what the expected behavior is. Is there supposed to be any support for
> copying RTF text and preserving any of the formatting, or is RTF text
> supposed to take on the formatting of the TLF text that it’s being pasted
> into?
>
> I had in my mind that pasting RTF has some support, but I’m not seeing
> that when I’m checking now.
>
> Harbs

Re: TextFlowLine recycling

[Joel Marks]

We have had

if (_curElementStart == _curParaStart+_curParaElement.textLength)
  break;

get off before because we accidentally edited the model during composition.

TLF really hates when you do that.

On Fri, Nov 7, 2014 at 2:50 AM, Erik de Bruin  wrote:

> No, please go ahead, I think showing progress and thoughts/ideas will be
> helpful to others, and it might even trigger someone with a solution.
>
> EdB
>
>
>
> On Fri, Nov 7, 2014 at 9:34 AM, Harbs  wrote:
>
> > A bit more progress: It looks like things go off where the text flows
> from
> > one container into another mid-paragraph…
> >
> > (Sorry for polluting the mailing list with this. I’ll try to be quiet
> > until I figure it out…)
> >
> > On Nov 7, 2014, at 9:55 AM, Harbs  wrote:
> >
> > > It’s pretty big.
> > >
> > > It consistently gets out of whack at the end of the second paragraph.
> > I’m getting closer to where it’s going off…
> > >
> > >
> > > On Nov 7, 2014, at 1:01 AM, Alex Harui  wrote:
> > >
> > >>
> > >>
> > >> On 11/6/14, 2:02 PM, "Harbs"  wrote:
> > >>
> > >>> I think it’s _curElementOffset which gets updated.
> > >>>
> > >>> It does look like something is getting out of sync. I’m just not sure
> > yet
> > >>> what. This is one of those areas that’s way too fragile IMHO… Every
> > time
> > >>> I’ve run into these kinds of issues it’s taken me days to figure out
> > >>> exactly what’s off.
> > >>
> > >> Is the paragraph huge?  In the past I simply have to watch each line
> get
> > >> created, figure out what is in the line, and how much the offset
> should
> > >> change and verify it changed.  This was when I was dealing with some
> > >> unicode character issues where an atom could be made of more than one
> > >> character.
> > >>
> > >> -Alex
> > >>
> > >
> >
> >
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>

Re: TextFlowLine recycling

[Joel Marks]

I think the root of the problem is that BaseCompose.createTextLine() is
returning null. The only reason why that would happen is if the line
couldn't fit in the space provided. I am not sure why
ComposeState.composeNextLine() is trying to do _curLine.getTextLine(true)
when the textLine is null. I would think you would hit the same result or
something worse like an RTE.

What parameters are you passing into FTE when trying to create the line?

On Thu, Nov 6, 2014 at 2:09 PM, Harbs  wrote:

> Yes. It’s very reproducible.
>
> Not small at all… :-(
>
> It would be considerable work to try to put together a test case for this.
>
> On Nov 6, 2014, at 9:41 PM, Alex Harui  wrote:
>
> > Do you have a 100% reproducible test case?  How small is it?
> >
> > On 11/6/14, 11:31 AM, "Harbs"  wrote:
> >
> >> If someone has the time to walk through this with me off-list, that
> would
> >> be very helpful. I’d really like an extra set of eyeballs to make sure
> >> I’m not missing something with this and I don’t blow things up. I don’t
> >> have a good enough grasp on exactly how the management of TextFlowLines
> >> is supposed to be working.
> >>
> >> On Nov 6, 2014, at 7:15 PM, Alex Harui  wrote:
> >>
> >>> My memory is a bit fuzzy.  I thought TextLine recycling wasn’t
> >>> per-paragraph, or is there a TextBlock per paragraph?
> >>>
> >>> The doc says that TextBlock.createTextLine/recreateTextLine returns
> null
> >>> if the TextBlock is empty or if the width specified is less than the
> >>> width
> >>> of the next element, and to check the TextBlock.textLineCreationResult
> >>> property if you get a null.
> >>>
> >>> Could it just be that the number of lines in the paragraph when to
> zero?
> >>>
> >>> -Alex
> >>>
> >>> On 11/6/14, 2:26 AM, "Harbs"  wrote:
> >>>
>  I ran into an issue where I have a runtime error in
>  TextFlowLine.getTextLine(). I’m having trouble stepping through
> things,
>  but as best as I can figure, the issue is caused by the umber of lines
>  in
>  a paragraph becoming reduced.
> 
>  The RTE happens inside TextFlowline.recreateTextLine() after
> requesting
>  the line from the TextBlock. The function (I’m not sure if it’s
>  createTextLine or recreateTextLine) returns null. The
>  TextBlock.lastLine
>  is the line before the current one.
> 
>  The caller of this mess is ComposeState.composeNextLine.
> 
>  If anyone is still following me, my problem is I’m not sure the best
>  way
>  to fix this. I’m not sure why this is breaking now. I’m not sure what
> I
>  changed that’s causing this error. Should I fix
>  TextFlowLine.getTextLine() to return null if there’s no more lines in
>  the
>  paragraph? Will there be any other repercussions from doing that?
>  Should
>  I fix ComposeState/BaseCompose  so it does not try to compose the next
>  line once the paragraph is out of lines?
> 
>  Is anyone familiar enough with the composer to even give me
>  suggestions?
>  :-(
> 
>  Harbs
> >>>
> >>
> >
>
>

Re: To FlexJS or not to FlexJS

[Joel Marks]

@Harbs we  are in a very similar position.
Unfortunately we have kind of given up on Flex but the grass hasn't been
very green on the other side.

Our production application which uses our custom version of TLF 1 is still
all in Flex.  But, we have a viewer that is in JS which is using a text
layout algorithm on the server then pass down drawing instructions and
placing character by character using SVG. We had to roll our own selection
because the one built in to SVG is crap. Apparently the performance of SVG
is still better than Canvas.

We implemented TLF and FTE layout in Python but have been battling the last
two years trying to get them in sync with Flex and we still are not there
yet.  Because of this, as we look to the new text editor we are looking at
writing it in either Dart so we can use it on the client but then also use
the Dart VM on the server or in Go then use GopherJS to compile it to JS.

We had a former Flex team using Typescript but they were frustrated with
some shortcomings due to the fact you are still in JS so they ported all
their code to Dart and that has been successful. It is slightly slower than
pure JS but worth it for the language and the hope of future performance in
Chrome.

Another team is just starting to leave Angular for Facebook's React using
Flux. We have had a decent amount of success with React and this will be
our first foray into Flux.

AtScript from the Angular team is also very interesting due to the fact
that it will be able to be compiled to Dart or JS but I think it is still
in the early stages.

I suggested this before and I know this will probably never happen but I
would love it if Adobe would open source FTE (which I am guessing is in C
or C++) so people could use Emscripten to compile to JS or execut it on the
server. If we have FTE then then TLF would be pretty easy to port or FlexJS
may just be able to keep the the same code. I know this is very much not
trivial but it could help the web so much by having a text engine that is
compatible across all browsers.

On Mon, Nov 3, 2014 at 3:59 PM, jude  wrote:

> I think staying with FlexJS will be a big advantage for you. You know many
> in the community who will be able to help and improve FlexJS, you'll get
> typed AS3 language support and MXML support for layout and markup.
>
> The only thing I would consider is the text support. I ran into issues with
> text layout in the HTML output as well. I was trying to go from Flash text
> layout to HTML output and the text in HTML was too high or too low or too
> wide and so on. That's just trying to output a static resource from what is
> visible in Flash. If you are doing printui interface in HTML you will have
> to figure out how to deal with text differences across browsers and the
> original source. It may require SVG or HTML canvas or a JS text library.
>
> Ted Patrick's been working on something called "txt" [0][1]. It looks like
> it's doing consistent layout of text across browsers but I couldn't find
> any more details than what he's posted on twitter. One comment I read is
> that it is matching the layout of text in InDesign. He may also import
> TLF[2]??? There is also seems to be an AutoSizeText [5].
>
> [0] https://twitter.com/__ted__/status/515128060291477504
> [1] https://twitter.com/__ted__/status/522748823475478528
> [2] https://twitter.com/__ted__/status/523105022007992320
> [3] https://www.youtube.com/watch?v=wB6mCJbDjaY
> [4] https://twitter.com/__ted__/status/515125174627074050
> [5] https://twitter.com/__ted__/status/513084940234153984
>
> On Mon, Nov 3, 2014 at 4:53 AM, piotrz  wrote:
>
> > Harbs,
> >
> > If you have any kind of possibility to stay with ActionScript development
> > just do this. I can say that AngularJS is a great framework, but if we
> are
> > trying to do something really big - debugging, searching in code, fast
> > creation of complex ui is far far a way from what we have seen in AS
> > development. - I see this in my team where they are working on really big
> > AngularJS app.
> >
> > I think if you successfully prototype your project in FlexJS you will
> give
> > this framework solid kick and push it to the next level!
> >
> > Just my small two cents on this.
> >
> > Piotr
> >
> >
> >
> > -
> > Apache Flex PMC
> > piotrzarzyck...@gmail.com
> > --
> > View this message in context:
> >
> http://apache-flex-development.247.n4.nabble.com/To-FlexJS-or-not-to-FlexJS-tp41998p42022.html
> > Sent from the Apache Flex Development mailing list archive at Nabble.com.
> >
>

Re: TextFlowLine recycling

[Joel Marks]

What was the stack trace?

On Thu, Nov 6, 2014 at 11:29 AM, Harbs  wrote:

>
> On Nov 6, 2014, at 7:15 PM, Alex Harui  wrote:
>
> > My memory is a bit fuzzy.  I thought TextLine recycling wasn’t
> > per-paragraph, or is there a TextBlock per paragraph?
>
> There’s generally one TextBlock per paragraph. My table work was actually
> quite difficult because there was an assumption in many places that there
> is ONLY one TextBlock per paragraph. Tables kind of blows that assumption
> out of the water…
>
>
> > The doc says that TextBlock.createTextLine/recreateTextLine returns null
> > if the TextBlock is empty or if the width specified is less than the
> width
> > of the next element, and to check the TextBlock.textLineCreationResult
> > property if you get a null.
>
> It looks to me that it’s null if you ask for a line beyond the last one as
> well.
>
> > Could it just be that the number of lines in the paragraph when to zero?
>
> No. The TextBlock has more than one line. The last line in the TextBlock
> is the line of the previous TextFlowLine.
>
> >
> > -Alex
> >
> > On 11/6/14, 2:26 AM, "Harbs"  wrote:
> >
> >> I ran into an issue where I have a runtime error in
> >> TextFlowLine.getTextLine(). I’m having trouble stepping through things,
> >> but as best as I can figure, the issue is caused by the umber of lines
> in
> >> a paragraph becoming reduced.
> >>
> >> The RTE happens inside TextFlowline.recreateTextLine() after requesting
> >> the line from the TextBlock. The function (I’m not sure if it’s
> >> createTextLine or recreateTextLine) returns null. The TextBlock.lastLine
> >> is the line before the current one.
> >>
> >> The caller of this mess is ComposeState.composeNextLine.
> >>
> >> If anyone is still following me, my problem is I’m not sure the best way
> >> to fix this. I’m not sure why this is breaking now. I’m not sure what I
> >> changed that’s causing this error. Should I fix
> >> TextFlowLine.getTextLine() to return null if there’s no more lines in
> the
> >> paragraph? Will there be any other repercussions from doing that? Should
> >> I fix ComposeState/BaseCompose  so it does not try to compose the next
> >> line once the paragraph is out of lines?
> >>
> >> Is anyone familiar enough with the composer to even give me suggestions?
> >> :-(
> >>
> >> Harbs
> >
>
>

Re: Open source parts of FP

[Joel Marks]

Thanks for the reply Mike. Sorry I didn't realize how well documented the
"open source parts of Flash" argument is.

Applications that rely on pixel perfect text layout can not use the browser
DOM because most everything in the browser world it is dependent on what
browser and OS you use.  This has led companies like Prezi, who is trying
to get off FP, to use Emscripten for HarfBuzz in the browser then they
completely wrote their own paragraph layout engine.


On Wed, Aug 27, 2014 at 6:13 PM, Michael A. Labriola <
labri...@digitalprimates.net> wrote:

> >Long story short we are trying to do what the Flash Player does outside
> of Flash. We have seen other companies have success using Emscripten and
> asm.js so if Adobe could open source parts of the Flash Player then we
> could get some of the Flash Player functionality in javascript. FTE and the
> Core Text Services C library (documentation <
> http://www.adobe.com/cn/devnet/flash/articles/tlf-overview.html>) inside
> of the Flash Player are of particular interest to me and anyone else that
> was using TLF in their Flex application. This also has potential of making
> the effort for Flex JS easier.
>
> Joel,
>
> I am not going to address the why won't adobe open source flash part of
> this, there are too many threads on that in this forum to count already.
> However, just want to point out that a lot of what FTE was trying to
> accomplish is bringing the rendering capabilities of the browser into Flash
> Player. So, porting something that does browser rendering in the player
> back to the browser is a bit circular if not redundant. We have found that
> everything FTE could do is generally available, faster and easier in the
> browser DOM today. This isn’t a comment on Flex versus JS in general, just
> on text rendering.
>
> Just something to think about,
> Mike
>
>
>

Open source parts of FP

[Joel Marks]

Our company chose Flex for obvious reasons six years ago and now we are
looking to what is next. We built an application that is similar to
Word/Excel/Powerpoint and we are heavily dependent on TLF (unfortunately
version 1 of TLF because we forked) and FTE.

Long story short we are trying to do what the Flash Player does outside of
Flash. We have seen other companies have success using Emscripten and
asm.js so if Adobe could open source parts of the Flash Player then we
could get some of the Flash Player functionality in javascript. FTE and the
Core Text Services C library (documentation
<http://www.adobe.com/cn/devnet/flash/articles/tlf-overview.html>) inside
of the Flash Player are of particular interest to me and anyone else that
was using TLF in their Flex application. This also has potential of making
the effort for Flex JS easier.

Thoughts?

Thanks,
Joel Marks
Workiva <https://www.workiva.com/> (formerly WebFilings)

Re: Table cell selection

[Joel Marks]

Our company created our own version of tables that we wanted to mimic more
closely to Excel than HTML tables. We are doing this by TLF recognizing the
table as being an InlineGraphicElement but we just replace the source with
a Sprite that has our custom table UI.

We have a ITableSelectionManager that extends ISelectionManager. Here are
some of the other things we have in our ITableSelectionManager

public interface ITableSelectionManager extends ISelectionManager,
IEventDispatcher, IDisposable
 {
function get table():IWFInternalTable;
function set table(value:IWFInternalTable):void
 function get composer():ITableComposer;
 function get pointEditModeAvailable():Boolean;
function set pointEditModeAvailable(value:Boolean):void;
 function getCommonTextFormat(range:TableRange=null):ITextLayoutFormat;
function getCommonValueFormat(range:TableRange=null):IValueFormat;
 function getCommonPrecisionAndScale(range:TableRange =
null):CommonValueFormatProperties;
function rangeContainsFormulaOrUsage(range:TableRange=null):Boolean;
 //Table Properties
function get selection():TableSelection;
 function setSelection(range:TableSelection, scrollDirection:String =
"both", forceCommit:Boolean = false, scrollToLimitRange:Boolean =
true):void;
 function get cutCopyRange():TableRange;
function set cutCopyRange(range:TableRange):void;
 function get allowedScrollDirection():String;
 function get isMouseDown():Boolean;
 function hasMultipleSelections():Boolean;

function get allRowsSelected():Boolean;
 function get allColumnsSelected():Boolean;

//used to track the controller events are coming from since we
 // can't pass in function since we need to match TLF interfaces
function get eventController():ITableContainerController;
 function set eventController(value:ITableContainerController):void;
function copyHandler(event:Event):void;
 function selectAllHandler(event:Event):void;
}


On Tue, May 27, 2014 at 1:54 PM, Harbs  wrote:

> I guess if we discover that it’s a problem, we can always revert
> ISelectionManager and create a new interface for cell selection. But I
> agree that it’s highly unlikely that it’s a problem.
>
> On May 27, 2014, at 9:46 PM, Alex Harui  wrote:
>
> > That's probably fine.  However, consider that some folks are using
> > third-party libraries that no longer have active developers so they won't
> > always be able to fix it.  Still, I will be surprised if we break
> anybody.
> >
> > -Alex
> >
> > On 5/27/14 9:32 AM, "Harbs"  wrote:
> >
> >> Okay. I’m going to just implement it in ISelectionManager. On the odd
> >> chance that I do break someone’s implementation, it should be a
> >> relatively easy job to add some blank functions to honor the interface
> >> promise (assuming they don’t need the table support).
> >>
> >> On May 27, 2014, at 6:22 PM, Alex Harui  wrote:
> >>
> >>> If someone has their own implementation of an interface, adding an API
> >>> to
> >>> an interface can break them.  The verifier will see that not all
> methods
> >>> are implemented.
> >>>
> >>> It is a trade-off.  You can create an ISelectionManager2 or
> >>> ITableSelectionManager to be completely safe, but the odds you will
> >>> break
> >>> someone is probably very low.
> >>>
> >>> -Alex
> >>>
> >>> On 5/27/14 3:47 AM, "Erik de Bruin"  wrote:
> >>>
>  Adding to an API shouldn't be a problem, as long as the new
>  methods/properties don't change anything about the existing
>  implementation...
> 
>  EdB
> 
> 
> 
> 
>  On Tue, May 27, 2014 at 12:42 PM, Harbs 
> wrote:
> 
> > I¹m working on cell selection of TLF tables.
> >
> > Cell selections does not fit into the normal index based selection
> > concept
> > of text. To support cell selection, I need coordinate-based selection
> > (to
> > support rectangular selections within a table).
> >
> > Basically, I want to add some table-specific functions to
> > ISelectionManager and SelectionManager. My question is whether this
> > might
> > cause problems for users who might have implemented ISelectionManager
> > and
> > whether I should be concerned about that and/or what there is to do
> > about
> > it.
> >
> > Thoughts?
> > Harbs
> 
> 
> 
> 
>  --
>  Ix Multimedia Software
> 
>  Jan Luykenstraat 27
>  3521 VB Utrecht
> 
>  T. 06-51952295
>  I. www.ixsoftware.nl
> >>>
> >>
> >
>
>

Re: TLF Markup to PDF

[Joel Marks]

We have tried xsl:fo before and abandoned it because we continually had
issues with it and it didn't match up that well.

We use AlivePDF and have a process where we take pixel positions of text
lines and add lines to the pdf in those positions using the characters on
those lines.

If you change formats in the middle of the line then you need to add
multiple lines to the pdf for a single line. It is a fairly complex
solution but it works very well.


On Wed, Mar 20, 2013 at 1:18 PM, Leo Sapucaia wrote:

> @Jarosław
> I think your sugestion will work for now and I´ll try that... but i´m
> making a document editor for a legal/juridic web application. I think my
> client will ask for a search feature soon.
> Thanks for reply!
>
> [ ]´s
> Leonardo Sapucaia
>
> --
> Leonardo Sapucaia
> NUIX: Natural User Interface eXperience
> Projetos Inovadores em TIC
> +55 (77) 8812-0158
> leo.sapuc...@gmail.com
>
>
> 2013/3/20 Jarosław Szczepankiewicz 
>
> > I'm not sure xsl:fo can handle all tlf requirements and it might be very
> > difficult to translate that to xsl:fo, althrough xsl:fo is mature
> standard
> > fop is not. The're still some quirks in fop. You will have to cope with
> two
> > difficult standards. I suggest trying to render to bitmap in higher dpi
> and
> > then send it to embed in pdf. Simples solution which will be 1:1
> fidelity,
> > but without search & indexing pdf.
> >
> > 2013/3/20 Leo Sapucaia 
> >
> > > Hi all,
> > >
> > > I´m looking for a solution for TLF to PDF export.
> > > I´m thinking maybe transform the TLF markup in XLS:FO and this in PDF
> via
> > > Apache FOP... or maybe something more direct, like the purePDF api.
> > >
> > > Someone worked in something like that?
> > > Any ideas?
> > >
> > > Cheers,
> > > Leonardo Sapucaia
> > >
> > > --
> > > Leonardo Sapucaia
> > > NUIX: Natural User Interface eXperience
> > > Projetos Inovadores em TIC
> > > +55 (77) 8812-0158
> > > leo.sapuc...@gmail.com
> > >
> >
>