embedded files in Word documents - any limitations?

[Callanish]

Can anyone tell me if there is any limit to the number of files that can be
embedded within a Word document? The files in question are other Word
documents - embedded as icons, not full text. I've heard that the maximum
filesize for a Word document is 32Mb - does anyone know if this is still true
for Word 2003?

I'm trying to anticipate potential problems to this approach, so any advice
would be much appreciated.

Thanks

Callanish

 

[Robert M. Franz (RMF)]

Hi Callanish

Can anyone tell me if there is any limit to the number of files that can be
embedded within a Word document? The files in question are other Word
documents - embedded as icons, not full text. I've heard that the maximum
filesize for a Word document is 32Mb - does anyone know if this is still true
for Word 2003?

The 32 MByte limit is not mentioned anywhere for Word 2003 anymore
AFAIK. FWIW, that limit always related to the raw text amount of the
document, so embedded pictures and other objects did not bring you to
that limit (your might run into other problems if your hardware or
installation is not generous enough, of course ).

2cents
Robert

 

[Callanish]

Thanks, Robert

That's very helpful - I'd not realised that embedded objects were excluded
anyway.

The hardware limitations might be more problematic for us - this method is
being considered as a way to send specificiations (held in multiple
documents) to clients whose Word skills (and possibly PC set-up) are not very
sophisticated.

I think some experimentation is required...

Thanks again,

Callanish

 

[Robert M. Franz (RMF)]

The hardware limitations might be more problematic for us - this method is
being considered as a way to send specificiations (held in multiple
documents) to clients whose Word skills (and possibly PC set-up) are not very
sophisticated.

Interesting: What exactly do you mean with "insert as icons", anyway? A
Hyperlink to a different file?

Greetinx
Robert

 

[Callanish]

Sorry, I'm not explaining myself too well! This is what I mean:

1) Insert > Object
2) On the Object dialog, select the "Create from File" tab
3) Check "Display as Icon" box, then Browse to the file, and OK

The main document would be a top-level summary document, containing the more
detailed design documents (inserted as above).

Do you think this is a completely mad thing to do? It's not my idea, I'm
just the technical writer! ;-)

Thanks again,

Callanish

 

[Robert M. Franz (RMF)]

Hi Callanish

Sorry, I'm not explaining myself too well! This is what I mean:

1) Insert > Object
2) On the Object dialog, select the "Create from File" tab
3) Check "Display as Icon" box, then Browse to the file, and OK

The main document would be a top-level summary document, containing the more
detailed design documents (inserted as above).

Do you think this is a completely mad thing to do? It's not my idea, I'm
just the technical writer! ;-)

OK, I see what you are doing. What is the ultimate purpose of this
document, BTW? Internal usage? Sending off with the product to the
customers?

I would not do it with objects. Inserted objects like this look rather
tricky to me, esp. when you imagine the lifecycle of such a document;
whether it should work on systems with different earlier and/or later
versions of Office installed, too, for instance.

If you really want to have a kind of "table of contents" document
(instead of bringing the content together in one file [directly, or via
INCLUDETEXT fields]), I'd try RD fields.

Greetinx
Robert

 

[CyberTaz]

Hi Robert-

If the doc size is that large and would contain many embedded docs, you
might be better off to create the finished product as a PDF... Especially if
the users are not expected to edit the file.

Regards |:>)

Hi Callanish

Sorry, I'm not explaining myself too well! This is what I mean:

1) Insert > Object
2) On the Object dialog, select the "Create from File" tab
3) Check "Display as Icon" box, then Browse to the file, and OK

The main document would be a top-level summary document, containing the more
detailed design documents (inserted as above).

Do you think this is a completely mad thing to do? It's not my idea, I'm
just the technical writer! ;-)

OK, I see what you are doing. What is the ultimate purpose of this
document, BTW? Internal usage? Sending off with the product to the
customers?

I would not do it with objects. Inserted objects like this look rather
tricky to me, esp. when you imagine the lifecycle of such a document;
whether it should work on systems with different earlier and/or later
versions of Office installed, too, for instance.

If you really want to have a kind of "table of contents" document
(instead of bringing the content together in one file [directly, or via
INCLUDETEXT fields]), I'd try RD fields.

Greetinx
Robert

-- (e-mail address removed)

 

[Callanish]

The purpose of the document is to enable clients to review software
specifications prior to the changes actually being built. In the past, all
changes were defined in a single spec, but we are in the process of
implementing RUP, which requires separate documents for each component - for
example, a screeen has its own UI prototype document, each process has a use
case document and so on.

We're trying to minimise clients' resistance to this change in their
process. We anticipate that they will (understandbly) be reluctant to review
multiple documents, where previously they would only have had one long
document to consider.

I share your reservations about using document objects, and was hoping to
find a technical reason to veto this approach. That's a good point about
conflicts between different versions, as we don't know precisely which our
clients are using.

Thanks for the suggestion about RD fields - not something I'd considered
before, but I'll give it a try.

C

Hi Callanish

Sorry, I'm not explaining myself too well! This is what I mean:

1) Insert > Object
2) On the Object dialog, select the "Create from File" tab
3) Check "Display as Icon" box, then Browse to the file, and OK

The main document would be a top-level summary document, containing the more
detailed design documents (inserted as above).

Do you think this is a completely mad thing to do? It's not my idea, I'm
just the technical writer! ;-)

OK, I see what you are doing. What is the ultimate purpose of this
document, BTW? Internal usage? Sending off with the product to the
customers?

I would not do it with objects. Inserted objects like this look rather
tricky to me, esp. when you imagine the lifecycle of such a document;
whether it should work on systems with different earlier and/or later
versions of Office installed, too, for instance.

If you really want to have a kind of "table of contents" document
(instead of bringing the content together in one file [directly, or via
INCLUDETEXT fields]), I'd try RD fields.

Greetinx
Robert
--
/"\ ASCII Ribbon Campaign | MS
\ / | MVP
X Against HTML | for
/ \ in e-mail & news | Word

 

[Robert M. Franz (RMF)]

The purpose of the document is to enable clients to review software
specifications prior to the changes actually being built. In the past, all
changes were defined in a single spec, but we are in the process of
implementing RUP, which requires separate documents for each component - for
example, a screeen has its own UI prototype document, each process has a use
case document and so on.

We're trying to minimise clients' resistance to this change in their
process. We anticipate that they will (understandbly) be reluctant to review
multiple documents, where previously they would only have had one long
document to consider.

I share your reservations about using document objects, and was hoping to
find a technical reason to veto this approach. That's a good point about
conflicts between different versions, as we don't know precisely which our
clients are using.

In that case, I'd rather consider using a bunch of INCLUDETEXT-fields:
you have all your individual files, and compile one large document for
each client by pointing to the parts with INCLUDETEXT. Best make one
template for each client, so you can open up a new document based on it
and right away unlink the fields. In effect, you have a single document
then, comprised of all the parts.

2cents
Robert

 

[Callanish]

Thanks, that sounds a real possibility - I'll give it a go.

Callanish

 

[Gerri]

Hi CyberTas,

If Robert converted all his INCLUDETEXT fields to RD fields, *ALL* the
individual chapter headings would apear as 1, 1.1, 1.1.1, etc in the ToC and
page numbering would restart at 1 for each Chapter.

Adding a {SEQ Chapter \r#} to EACH chapter (substituting # for the actual
chapter number) and using {SEQ Chapter \c}-{Page} for the page numbering and
adding \s Chapter to the {TOC} field inthe "Master" would resove the page
numbering but not the Heading numbering.

Any clues how to get the TOC to reflect 37.1, 37.1.1 etc for the heading in
Chapter 37?

Cheers,
Gerri
--
Gerri, Tech Writer
Australia

Hi Robert-

If the doc size is that large and would contain many embedded docs, you
might be better off to create the finished product as a PDF... Especially if
the users are not expected to edit the file.

Regards |:>)

Hi Callanish

Sorry, I'm not explaining myself too well! This is what I mean:

1) Insert > Object
2) On the Object dialog, select the "Create from File" tab
3) Check "Display as Icon" box, then Browse to the file, and OK

The main document would be a top-level summary document, containing the more
detailed design documents (inserted as above).

Do you think this is a completely mad thing to do? It's not my idea, I'm
just the technical writer! ;-)

OK, I see what you are doing. What is the ultimate purpose of this
document, BTW? Internal usage? Sending off with the product to the
customers?

I would not do it with objects. Inserted objects like this look rather
tricky to me, esp. when you imagine the lifecycle of such a document;
whether it should work on systems with different earlier and/or later
versions of Office installed, too, for instance.

If you really want to have a kind of "table of contents" document
(instead of bringing the content together in one file [directly, or via
INCLUDETEXT fields]), I'd try RD fields.

Greetinx
Robert

-- (e-mail address removed)

 

[Robert M. Franz (RMF)]

Hi Gerri

If Robert converted all his INCLUDETEXT fields to RD fields, *ALL* the
individual chapter headings would apear as 1, 1.1, 1.1.1, etc in the ToC and
page numbering would restart at 1 for each Chapter.

I don't think that Robert would do that, though.

Adding a {SEQ Chapter \r#} to EACH chapter (substituting # for the actual
chapter number) and using {SEQ Chapter \c}-{Page} for the page numbering and
adding \s Chapter to the {TOC} field inthe "Master" would resove the page
numbering but not the Heading numbering.

But that would only take care of the visible page number in the chapter;
the TOC would still reflect whatever a PAGE field shows on the page (for
a given heading) in the chapter file.

Any clues how to get the TOC to reflect 37.1, 37.1.1 etc for the heading in
Chapter 37?

If you work with RD fields, you have to get the numbering (pages _and_
chapters) straight in all single files before you start compiling TOCs
etc. I've seen macros out there which adjust the page numbering of the
individual files (setting the "Start at" property of the first section
of each file, I presume), so that chapter (n+1) starts at page (<end of
chapter n>+1).

I've never seen code to adjust the outline numbering in a similar way. I
don't think SEQ works here, but maybe LISTNUM fields?

An alternative approach would be to leave the chapter number away
entirely (in the, say, Heading 1 style) and number the corresponding TOC
style (see the thread "Heading style problem" starting 2005-oct-13 in
this NG).

Greetinx
Robert