[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: FrameMaker document model [was 'Re: Wish List - Conditional text COLUMNS IN
From: hedley_finger () myob ! com ! au
Date: 2002-11-22 3:39:07
[Download RAW message or body]
----- Forwarded by Hedley Finger/AU/MYOB on 22/11/2002 14:35 -----
\
Hedley Finger \
To: Thomas Zander \
<zander@planescape.com> \
22/11/2002 cc: \
14:33 Subject: FrameMaker document model [was \
'Re: Wish List - Conditional text COLUMNS IN A
TABLE'] \
\
Thomas:
I mislaid your email address after David Faure originally communicated with
me.
You asked if it were okay if, initially, an anchored frame simply appeared
inline (or was that hanging below a paragraph?).
I think that you should go beyond the simple anchored frame concept and
consider a Figure object, similar to a single-celled table in some
respects:
@ Must be able to manipulate it as a single object.
@ Must be able to create Figure formats (like Table formats).
@ Title can appear above or below or at the side; title attributes same
as Paragraph object.
@ Additional Caption object required, also a Paragraph object with
positioning attributes.
Figure 1.2 Workflow for grading incoming logs // Title
+-----------------------------------------------+ // Anchored
frame
| |
| |
. .
: :
| |
| |
+-----------------------------------------------+
This flowchart is based on that at the Ogone(a) // Caption
(with footnote ref)
mill but is similar to those in other mills
within the Forest Renewals group
a Ogone later reverted to a simplified workflow // Figure
footnote
similar to the Australian Paper Originators
workflow
In FrameMaker, Table and Anchored Frames objects can only have one of
several placements, e.g. Anywhere OR Top of Column OR Top of Right Page,
etc. I suggest that a more flexible scheme would be to have LIST of
preferred placements, e.g.
Anywhere
Top of Page
Top of Column
Bottom of Page
...
The layout engine would then try to place the object in its preferred
position and, if that was impossible, in the second preferred position, and
so on.
Please see the bare mention of other layout improvements that could be
incorporated into Kword in the list of suggestions below originally sent to
a FrameMaker list.
Hedley
--
Hedley Finger
Technical Communications/Technical communicator and FrameMaker mentor
MYOB Australia <http://www.myob.com.au/>
P.O. box 371 Blackburn VIC 3130 Australia
12 Wesley Court Tally Ho Business Park East Burwood VIC 3151
Australia
<mailto:hedley_finger@myob.com.au>
Tel. +61 3 9222 9992 x 7421, Mob. (cell) +61 412 461 558
(C) MYOB Limited 2002
----- Forwarded by Hedley Finger/AU/MYOB on 22/11/2002 14:18 -----
\
Hedley Finger \
To: "Free Framers" <framers@omsys.com>, \
framers@frameusers.com
18/11/2002 cc: \
11:46 Subject: FrameMaker document model [was \
'Re: Wish List - Conditional text COLUMNS IN A
TABLE'](Document link: Hedley Finger) \
\
All:
Thomas Michanek stated in passing that ...
> It is clear that Adobe doesn't want, and never will, rewrite the FM
> code and the document model to support new features that require
> such rewrites. This is why, for instance, Unicode "support" in FM7
> was implemented using markers instead of rewriting the way characters
> are stored. Perhaps Adobe will do such a rewrite for FM8, but they
> are apparently very afraid to touch the internal workings of FM.
In fact, if you look at all the changes since FM 4.0, they have largely
been cosmetic changes to the GUI or to improve usability, and very few have
addressed the underlying document model (think MIF) or the renderer (think
screen and print output).
There have been a few useful additions, such as more Running H/F variables
but so much more desperately needs to be done to make FrameMaker a
distinctive tool that supports common practices in book publishing.
A quick checklist:
@ Working in double-spreads instead of single pages (graphics and tables
spanning two facing pages, footnotes balancing across pages)
@ Master page applied according to table format, like current
application by paragraph format.
@ Foot-of-page, end-of-chapter, or end-of-book notes, or multiple
combinations of these, such as asterisked footnotes coexisting with
numbered chapter notes or citations -- as Word can do now.
@ Integration of a bibliographic database utility or interfaces to
biblio database software to allow automatic updating.
@ In a long table, table footnotes appear at the appropriate break (if a
footnote marker is in row 2 on page 1, the footnote should be on page 1
too, not page 4)
@ Integration of better indexing tools, e.g. something like Cindex or
Sky Index that works with markers.
@ Paragraph properties:
-- Inside or Outside alignment (like Left and Right but determined by
page),
-- Top, Middle, or Bottom of Page/Column for chapter headings (only
available in table cells at the moment),
-- Frame Behind with x and y offsets to augment Frame Above and Frame
Below.
@ Cross-reference formats that automatically change depending on
whether:
-- the target is above or below on the same page (see Table 1.2 above)
-- the target is on the opposite page (see Table 1.2 facing)
-- the ref. is on a right and the target is on the following left (see
Table 1.2 following)
-- the ref. is on a left and the target is on the preceding right (see
Table 1.2 preceding)
-- the target is far away (see Table 1.2, 'Comparison of Asian and
Western diets', on page 49)
@ A Figure object containing Title, Caption, and Anchored Frame
subobjects that can be handled as a single unit, similar to a Table object.
This situation is very common in mature software. Four factors ensure that
little will be done:
@ Typically new enhancements are incremental changes to a huge codebase
that can be handled by a very small team of programmers and testers
extending the current API. If the document model is not extensible and is
embedded in spaghetti code, the costs of substantial changes to the
document model and renderer are huge.
@ Pressure from the market to keep prices down.
@ Pressure from shareholders to keep profits up (also see note above
about cheapness of minor incremental improvements).
@ De facto monopoly ensuring that no substantive changes need be made to
keep or increase market share. Wouldn't be nice if Ventura Publisher or
Kword were serious competitors?
My dream is that Graeme Forbes will see footnotes fixed within his lifetime
-- and mine.
Regards,
Hedley
--
Hedley Finger
Technical Communications/Technical communicator and FrameMaker mentor
MYOB Australia <http://www.myob.com.au/>
P.O. box 371 Blackburn VIC 3130 Australia
12 Wesley Court Tally Ho Business Park East Burwood VIC 3151
Australia
<mailto:hedley_finger@myob.com.au>
Tel. +61 3 9222 9992 x 7421, Mob. (cell) +61 412 461 558
(C) MYOB Limited 2002
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic