The native importer (abi/src/wp/impexp/ie_imp_AbiWord_1.cpp -- a very
long file name, no?) is a good place to look to see how we translate
props into internal attributes. The short is, the importer just passes
the attributes to the piece table "Document" class which does the job of
filling the piece table (and creating things like notions of
"paragraphs"
and the right change records for undo, etc.). As a footnote, for
historical
reasons, sometimes "paragraphs" are referred to as "strux", "blocks", or
"structures" in the layout/ptbl code.
In IE_Imp_AbiWord_1::_startElement(name, atts), the case for TT_BLOCK
does this:
X_VerifyParseState(_PS_Sec); // expat stuff
m_parseState = _PS_Block;
X_CheckError(m_pDocument->appendStrux(PTX_Block,atts)); // business
return;
The call to appendStrux() does the insertion, passing the atts in.
appendStrux() (in abi/src/text/ptbl/xp/pd_Document.cpp) really does:
return m_pPieceTable->appendStrux(pts,attributes);
... so the piece table's appendStrux() (in
abi/src/text/ptbl/xp/pt_PT_AppendStrux.cpp) does all the actual parsing
of
attributes to internal values.
-- back to the importer --
If you take gdb to the importer, at the level where it's handling the
TT_BLOCK case, and look at the atts, you'll see they're a list of
strings very close to the actual document format, and close to CSS2
properties. They're a prop,val list double-null-terminated, like:
const XML_Char ** attributes = {"indent", "1in",
"color", "#00ff00",
0, 0};
I think that's right... it's been a while since I've done document
format stuff.
I think the Word importer just needs to convert those tags to something
useful internally. Take a look at the other importer/exporter code
to see how we do mapping (abi/src/wp/impexp/xp).
Hope that didn't just confuse things.
-- Shaw Terwilliger