Skip to main content
1-Visitor
September 14, 2011
Question

WYSIWYG for tables in Editor view?

  • September 14, 2011
  • 55 replies
  • 11926 views

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 🙂

    55 replies

    1-Visitor
    September 19, 2011
    And that's the key. The people doing editing/authoring are still thinking of themselves as 'end users' while doing that function, when in actuality, they're a part of the provision of that end user experience. Yes, to some degree, you can do some 'editing' of data on those devices, but not at the fundamental levels we're talking about in the Editor view.

    My $.02,
    Steve Thompson
    +1(316)977-0515
    1-Visitor
    September 19, 2011
    There are some things you can't see in Arbortext Editor, such as page breaks caused by flowtext in the output and side-by-side (algroup) formatting.
    1-Visitor
    September 19, 2011
    Use the editing view for the output environment you're choosing. Why not put computers to work?
    1-Visitor
    September 19, 2011
    Arbortext reminds me of when cold type first became popular in the 70's.....a bunch of code adaptable to whatever....many times I feel like we are taking steps backwards.
    1-Visitor
    September 19, 2011
    If that's what you want, prepare to pay big $$$ for editing environments that support WYSIWYG for every possible output. Maybe the government will pay for it.
    1-Visitor
    September 19, 2011
    Government isn't paying for much of anything anymore...not Defense anyway. Just getting funding for the bare minimum is getting harder and harder.
    1-Visitor
    September 20, 2011

    How about "WYSICWYG (What You See Is Coincidentally What you Get)"? This is what I stress to our Training Team when they migrate people from Word to Arbortext. It's useful to make the point to people that what they see on screen might resemble what they see in print or online (ours is an online product), but unlike Word, this resemblance is not a direct consequence of the markup they use, and that furthermore they should concentrate on getting the semantics correct, and now worry too much about the display. To re-inforce the point we've deliberately left the FOSI looking different from the product.


    Our editorial XML goes through multiple transformations before ultimately appearing as HTML in a browser, and our authors understand that any one of those processes (or an unsupported browser/version) could cause the final product to display differently than expected.


    Having said all that, XML tables are something of a paradox.

    1-Visitor
    September 20, 2011
    Raise your hand if you have specifically customized a screen stylesheet
    because editing one "row" or construct (or tree) is easier with a vertical
    relationship between an item and its descendants or attributes while
    scanning / reading / comparing the same information in volume (the forest)
    requires a horizontal relationship.

    Or customized a screen stylesheet to eliminate or reduce the amount of
    generated text for performance purposes (although with infinite processing
    power, one might avoid this effort).

    Suzanne: If anyone expressed interest, I missed it, but it is clear that
    there is a wealth of information and experience that could be compiled into
    quite a screen stylesheet presentation!


    On Tue, Sep 20, 2011 at 1:47 AM, John Hanratty <
    john.hanratty@lexisnexis.co.uk> wrote:

    > How about "WYSICWYG (What You See Is Coincidentally What you Get)"? This is
    > what I stress to our Training Team when they migrate people from Word to
    > Arbortext. It's useful to make the point to people that what they see on
    > screen might resemble what they see in print or online (ours is an online
    > product), but unlike Word, this resemblance is not a direct consequence of
    > the markup they use, and that furthermore they should concentrate on getting
    > the semantics correct, and now worry too much about the display. To
    > re-informce the point we've deliberately left the FOSI looking different
    > from the product.
    >
    > Our editorial XML goes through multiple transformations before ultimately
    > appearing as HTML in a browser,a nd our authros understand that any one of
    > those processes (or an unsupported browser/version) could cause the final
    > product to display differently than expected.
    >
    > Having said all that, XML tables are something of a paradox, since they are
    > inherently layout-specific.
    >
    18-Opal
    September 20, 2011
    Hi Paul-



    (Hand raised.)



    To amplify, I think this is a critical point, and one of the most
    important concepts of structured authoring: that the optimal format for
    creating content may not be the same as the optimal format for
    presenting (reading) it. This is why it's important to shake authors out
    of the WYSIWYG mindset, so they can focus on optimizing content rather
    than aiming for a specific output appearance.



    This topic (screen stylesheets and why they matter) is a great one, and
    would have value far beyond the usual audience of XML geeks like those
    of us on this list. If done right, it would be something that would help
    authors understand why they shouldn't expect the editor screen to look
    like their generated PDF-and why that's a Good Thing(tm) (at least in
    many circumstances).



    --Clay



    Clay Helberg

    Senior Consultant

    TerraXML


    1-Visitor
    September 20, 2011
    Hi Paul!
    Would you or others be interested in getting together on this?
    Suzanne