WYSIWYG for tables in Editor view?

[mramshaw]

Several of our users are complaining that tables in the Editor view don't look like they do when composed in a print preview. Tables have no identation in our editor view but they have the standard 1" margin when you do a print preview and I was wondering if there was any way to have the indentation in the Editor view as well, as well as make it more WYSIWYG looking. I know it's last century technology 🙂

[JasonBuss]

...smells more like somebody losing a bet.

Of course, if it ever caught on, there'd actually be a domestic job market to support more than, say, 30 FOSI developers.

[bibach]

On Tue, Sep 20, 2011 at 2:58 PM, Buss, Jason A
<jabuss@cessna.textron.com> wrote:
> ...smells more like somebody losing a bet.

Ah, but don't all great technological marvels have at least a hint of
"because I could" in their origin?

> Of course, if it ever caught on, there'd actually be a domestic job market to support more than, say, 30 FOSI developers.

Well, with all the legacy stuff out there, there should be a steady
flow of work in the FOSI world. The problem is the low turnover.
After all, old FOSI developers never die... they just reach the
<textbrk endln="0">.

(Groan... clearly, someone has been without sleep for a few too many hours...)

-Brandon 🙂

[bibach]

Er... endln="1"... see note re: lack of sleep...

-Brandon 🙂


On Tue, Sep 20, 2011 at 3:09 PM, Brandon Ibach
<brandon.ibach@single-sourcing.com> wrote:
> On Tue, Sep 20, 2011 at 2:58 PM, Buss, Jason A
> <jabuss@cessna.textron.com> wrote:
>> ...smells more like somebody losing a bet.
>
> Ah, but don't all great technological marvels have at least a hint of
> "because I could" in their origin?
>
>> Of course, if it ever caught on, there'd actually be a domestic job market to support more than, say, 30 FOSI developers.
>
> Well, with all the legacy stuff out there, there should be a steady
> flow of work in the FOSI world. The problem is the low turnover.
> After all, old FOSI developers never die... they just reach the
> <textbrk endln="0">.
>
> (Groan... clearly, someone has been without sleep for a few too many hours...)
>
> -Brandon 🙂
>
>

[JasonBuss]

>Well, with all the legacy stuff out there, there should be a steady flow of work in the FOSI world. The problem is the low turnover.
After all, old FOSI developers never die... they just reach the <textbrk endln="0">.

You're killin' me, Smalls...

[ptc-1908075]

Believe it or not, I sometimes compose email that is not short in AE (just in paragraph elements) so I don't have to deal with formatting and to use the thesaurus. Also, selecting just the characters you want is easier in AE than some editors, and AE deletes a word space when it deletes a word, which is less work for me.

An AE-based native XML mailer with FOSI formatting sounds like a great idea to me! 😆 I'll have to give some thought to a name ...

[ClayHelberg]

Check it out: fun with ActiveX...







Clay Helberg

Senior Consultant

TerraXML

[ptc-1908075]

XMaiL?

[ptc-953926]

To much like XMetaL...

[ptc-1908075]

You're right.
S.

[ptc-1908075]

TreeMail?

[GarethOakes]

Haha I love it. I will have to come up with some witty riposte using the
ActiveX version of APP Desktop J *looks at pile of work* .. or not L



-G

[ebenton]

I'd use it.

[JasonBuss]

MetaMail?



Still has that awful Ribbon, though...

[steve.thompson4]

MyXMaiL

Slight update to keep the acronym.

If you don't like the Ribbon (hate it myself), just minimize it (down arrow next to the Quick Access Toolbar [QAT]). Gives you back the screen real estate, and makes it work like the menu once did. And seriously consider customizing that QAT: almost never need the Ribbon, now.

Less than $.02,
Steve Thompson
+1(316)977-0515

[ptc-3050150]

MinxMail

My Integrated [n-word] XML Mail

Hmmm, loses the whole Arbortext (or any leafy deciduous vegetation) reference.

[berard]

Best. Thread. Ever.

On Wed, Sep 21, 2011 at 9:39 AM, Jarrett, John T (US SSA) <
-> wrote:

> MinxMail****
>
> ** **
>
> My Integrated [n-word] XML Mail****
>
> ** **
>
> Hmmm, loses the whole Arbortext (or any leafy deciduous vegetation)
> reference.****
>
> ** **
>
> *From:* EXT-Thompson, Steve [

[ptc-1908075]

It looks like there are 4 of us interested in pursuing this 🙂

It occurs to me that a presentation on why WYSIWYG is last-century technology might be useful. Whaddya think? Anyone interested in contributing?

Suzanne

[ClayHelberg]

I can contribute if you are willing to organize the thing.



Clay Helberg

Senior Consultant

TerraXML

[ptc-1908075]

That would be great!
Thanks!
Suzanne

[mramshaw]

My office would like to contribute too (since we started this whole mess 🙂 ).

[ptc-1908075]

Thanks!
Suzanne

[mramshaw]

I thought I'd resurrect this thread with another question relating to WYSIWYG. Users are complaining that in tables they cannot see a page break when the table spans across pages like in Word. Is there any way to do this without a forced page break?

[naglists]

Not within the Edit Window. In the Edit Window, though, Editor has no
concept of a printed page so where the page breaks fall is unknown, let
alone un-shown.

Someone mentioned having a customized table output preview app that may /
probably has it (Gareth?). Not sure how it can without rendering at least
from the last force page break before the table.

[steve.thompson4]

We had a customer who needed XML with page breaks that imitated the printed page, to simplify their translation efforts. This is possible, to some degree, using Print Composer, but is not supported in PE.

It uses the "atipl tags" noted (and info linked) in Help # 722. It does "accommodate" tables, but there are a few caveats. The Help entry is about line numbering, but you will note that it mentions page numbers "displayed in the Edit window".

It required some adaptation of the ACL found in their "line numbering application", so it's not a simple matter of loading and using the application, but can be accomplished with brief study of the Help and the linked "atipl" information.

HTH,
Steve Thompson
+1(316)977-0515

[GarethOakes]

Hi Mike,



I think you'll find this opens a can of worms (nest of snakes?). Arbortext
screen view and the printed page are entirely divorced from each other. The
guiding paradigm is that authors should never worry about the printed page,
but concentrate on the subject matter (authored content).



Tables, of course, throw a hairy curveball at that model because editing XML
tables is all about knowing what size they are going to be, where the
columns will fall and so on. We have found in our experience that a good
halfway house is to have regular editing in Arbortext Editor but for tables
enable a "table preview" feature. This feature extracts the currently
selected table from the XML and sends it through print composition,
displaying the composed result to the author/editor.



The catch here, of course, is you are not seeing the true pagebreaks that
will occur in the printed output, but it turns out that most of the time
that isn't as important. The fact that users can play with the table
rotation and table/column widths is good enough. They can then get a feel
for the vertical size of a table and make decisions accordingly (without
necessarily seeing the precise page break that will occur in the final
output).



The good news is that Arbortext print composition can do a fairly good job
at handling page breaks in tables (eg. re-inserting table column heads and
so on). The so-called "deepcontentsplitting" can be a bear but I suspect in
your case the table preview feature would be good enough to address the
concerns you have encountered. BTW, the table preview feature is not an
out-of-the-box Arbortext thing. We have always had to write custom code to
get that working.



Cheers,

Gareth



PS. while on this topic, I can't help but describe the other radically
different way to handle printed XML tables. What you have to do is disallow
authors/editors from specifying table/column attributes for the widths and
so on. This means you are not allowing them to make decisions about the
table appearance.



Instead: you force the print composition system to make all the decisions
required to produce a correctly formatted table. This is an extremely
complex task for a print composition system to perform and we have only ever
had that working with APP/3B2 (Arbortext Advanced Print Publisher). It took
a lot of blood, sweat and tears. It is really cool when it works though!!

[mramshaw]

Thanks for the responses all! This is also supposed to be accomplished automatically without hitting a button but that seems impossible as I also can't limit what to do with the table. It looks like the best I could do is write something like the suggested table preview feature. We use atipl tags for line numbering with different doctypes but never display them as that seems to frighten and confuse the user, we go through a whole custom thing where we add the atipl tags for print/preview output and then strip them off immediately. I guess I could use them and leave them on the screen for this case.