Converting fm files to xml
Dear Framers, I am trying to save lots of .fm files as .xml in FM 7.2. I've written an application and when I save a single .fm file as .xml it works fine. When I use the Utility: File > Utilities > Convert structured documents, something goes wrong. The conversion runs fine but the 'href' attribute for the images is not included in the output files. My rules file includes the line: attribute "href" is fm property file; And, as I say, when I save an individual file as xml it's fine, so it looks like a bug. Does anyone have any ideas how to fix or workaround this? Thanks, Daniel Daniel Osborn?|?Usability Engineer - Technical Writer?| TomTom | daniel.osborn at tomtom.com | +44 (0)?161?408 7107 This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
Converting fm files to xml
Dear Framers, I am trying to save lots of .fm files as .xml in FM 7.2. I've written an application and when I save a single .fm file as .xml it works fine. When I use the Utility: File > Utilities > Convert structured documents, something goes wrong. The conversion runs fine but the 'href' attribute for the images is not included in the output files. My rules file includes the line: attribute "href" is fm property file; And, as I say, when I save an individual file as xml it's fine, so it looks like a bug. Does anyone have any ideas how to fix or workaround this? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | [EMAIL PROTECTED] | +44 (0) 161 408 7107 This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
XML roundtripping - attributes with more than one value
Hi Lynne,
Thanks for spending so much time on this and I'm sorry to bug you again.
I'm afraid I'm still a bit lost though. All my 'other' attributes are
already #IMPLIED. I tried changing the NMTOKENS attribute to #REQUIRED
(from #IMPLIED) but this didn't make any difference.
Any suggestions?
Thanks,
Daniel
Daniel Osborn | Usability Engineer - Technical Writer | TomTom |
daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office
-Original Message-
From: Lynne A. Price [mailto:lpr...@txstruct.com]
Sent: Wednesday, November 01, 2006 9:50 PM
To: Daniel Osborn; framers at lists.frameusers.com
Subject: RE: XML roundtripping - attributes with more than one value
Daniel,
You seem to have stumbled on a rather bizarre FM bug. Consider the
following XML document:
]>
It is reasonable to expect the test attribute of the test element to be
treated the same way as the test attribute of the bug element. However,
the
attribute on test is interpreted as two strings while that on bug as
only one.
Furthermore, the significant difference seems to be the definition of
the
other attribute. If the definition of that attribute is removed, bug's
test
attribute is processed correctly. The order of the two attribute
definitions in the declaration does not matter. If the default value of
other is changed to #IMPLIED or #REQUIRED, then test imports correctly.
I've tested on Windows in FM 7.2p158 and 7.1b023.
--Lynne
At 06:33 AM 10/26/2006, Daniel Osborn wrote:
>Does this mean that I should change the attribute type in the DTD to
>NMTOKENS? (At the moment it's CDATA.) I tried this but nothing changed.
>Have I done the wrong thing?
Daniel,
Yes, you want the attribute type in the DTD to be NMTOKENS. And,I
have
no idea if you've done the wrong thing!
--Lynne
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application
development,
and training
lprice at txstruct.com http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
RE: XML roundtripping - attributes with more than one value
Hi Lynne,
Thanks for spending so much time on this and I'm sorry to bug you again.
I'm afraid I'm still a bit lost though. All my 'other' attributes are
already #IMPLIED. I tried changing the NMTOKENS attribute to #REQUIRED
(from #IMPLIED) but this didn't make any difference.
Any suggestions?
Thanks,
Daniel
Daniel Osborn | Usability Engineer - Technical Writer | TomTom |
[EMAIL PROTECTED] | +31 (0) 20 8500 934 office
-Original Message-
From: Lynne A. Price [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 9:50 PM
To: Daniel Osborn; framers@lists.frameusers.com
Subject: RE: XML roundtripping - attributes with more than one value
Daniel,
You seem to have stumbled on a rather bizarre FM bug. Consider the
following XML document:
]>
It is reasonable to expect the test attribute of the test element to be
treated the same way as the test attribute of the bug element. However,
the
attribute on test is interpreted as two strings while that on bug as
only one.
Furthermore, the significant difference seems to be the definition of
the
other attribute. If the definition of that attribute is removed, bug's
test
attribute is processed correctly. The order of the two attribute
definitions in the declaration does not matter. If the default value of
other is changed to #IMPLIED or #REQUIRED, then test imports correctly.
I've tested on Windows in FM 7.2p158 and 7.1b023.
--Lynne
At 06:33 AM 10/26/2006, Daniel Osborn wrote:
>Does this mean that I should change the attribute type in the DTD to
>NMTOKENS? (At the moment it's CDATA.) I tried this but nothing changed.
>Have I done the wrong thing?
Daniel,
Yes, you want the attribute type in the DTD to be NMTOKENS. And,I
have
no idea if you've done the wrong thing!
--Lynne
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application
development,
and training
[EMAIL PROTECTED] http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
___
You are currently subscribed to Framers as [EMAIL PROTECTED]
Send list messages to [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [EMAIL PROTECTED] Visit
http://www.frameusers.com/ for more resources and info.
RE: XML roundtripping - attributes with more than one value
Hi Lynne, I've changed the type of the attribute in the DTD, but it doesn't have any effect. The attributes still appear in one line separated by spaces. Perhaps I should rephrase my second question (not wishing to give the wrong impression). Is there anything else I need to do to get this to work? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office -Original Message- From: Lynne A. Price [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 6:47 PM To: Daniel Osborn; framers@lists.frameusers.com Subject: RE: XML roundtripping - attributes with more than one value At 06:33 AM 10/26/2006, Daniel Osborn wrote: >Does this mean that I should change the attribute type in the DTD to >NMTOKENS? (At the moment it's CDATA.) I tried this but nothing changed. >Have I done the wrong thing? Daniel, Yes, you want the attribute type in the DTD to be NMTOKENS. And,I have no idea if you've done the wrong thing! --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training [EMAIL PROTECTED]http://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
RE: XML roundtripping - attributes with more than one value
Hi Lynne, Does this mean that I should change the attribute type in the DTD to NMTOKENS? (At the moment it's CDATA.) I tried this but nothing changed. Have I done the wrong thing? Thanks for your help, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office -Original Message- From: Lynne A. Price [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 25, 2006 7:57 PM To: Daniel Osborn; framers@lists.frameusers.com Subject: Re: XML roundtripping - attributes with more than one value At 10:27 AM 10/24/2006, Daniel Osborn wrote: >In Framemaker, when you add more than one value to an attribute of type >'Strings', the values have to be separated by a line break. > >When you save the file as .xml the values of the attribute are written >into one string separated by spaces. No problem there except that when >you open the file again in Framemaker the values are also written on one >line separated by spaces. > >Is there any way to reintroduce the line breaks into the attribute value >when the file is opened in Framemaker? Daniel, The FrameMaker attribute type Strings corresponds roughly to the XML attribute NMTOKENS. XML, however, restricts the different tokens to name characters and FM does not. In particular, FM permits white space within a particular string and XML does not. When FM opens an XML document that has a DTD, it interprets spaces within the value of a NMTOKENS attribute as a token separator. It displays each token on a separate line in the Structure View and in the Attributes window and dialog box. --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training [EMAIL PROTECTED]http://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284 ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
XML roundtripping - attributes with more than one value
Hi Lynne, I've changed the type of the attribute in the DTD, but it doesn't have any effect. The attributes still appear in one line separated by spaces. Perhaps I should rephrase my second question (not wishing to give the wrong impression). Is there anything else I need to do to get this to work? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office -Original Message- From: Lynne A. Price [mailto:lpr...@txstruct.com] Sent: Thursday, October 26, 2006 6:47 PM To: Daniel Osborn; framers at lists.frameusers.com Subject: RE: XML roundtripping - attributes with more than one value At 06:33 AM 10/26/2006, Daniel Osborn wrote: >Does this mean that I should change the attribute type in the DTD to >NMTOKENS? (At the moment it's CDATA.) I tried this but nothing changed. >Have I done the wrong thing? Daniel, Yes, you want the attribute type in the DTD to be NMTOKENS. And,I have no idea if you've done the wrong thing! --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training lprice at txstruct.comhttp://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284
XML roundtripping - attributes with more than one value
Hi Lynne, Does this mean that I should change the attribute type in the DTD to NMTOKENS? (At the moment it's CDATA.) I tried this but nothing changed. Have I done the wrong thing? Thanks for your help, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office -Original Message- From: Lynne A. Price [mailto:lpr...@txstruct.com] Sent: Wednesday, October 25, 2006 7:57 PM To: Daniel Osborn; framers at lists.frameusers.com Subject: Re: XML roundtripping - attributes with more than one value At 10:27 AM 10/24/2006, Daniel Osborn wrote: >In Framemaker, when you add more than one value to an attribute of type >'Strings', the values have to be separated by a line break. > >When you save the file as .xml the values of the attribute are written >into one string separated by spaces. No problem there except that when >you open the file again in Framemaker the values are also written on one >line separated by spaces. > >Is there any way to reintroduce the line breaks into the attribute value >when the file is opened in Framemaker? Daniel, The FrameMaker attribute type Strings corresponds roughly to the XML attribute NMTOKENS. XML, however, restricts the different tokens to name characters and FM does not. In particular, FM permits white space within a particular string and XML does not. When FM opens an XML document that has a DTD, it interprets spaces within the value of a NMTOKENS attribute as a token separator. It displays each token on a separate line in the Structure View and in the Attributes window and dialog box. --Lynne Lynne A. Price Text Structure Consulting, Inc. Specializing in structured FrameMaker consulting, application development, and training lprice at txstruct.comhttp://www.txstruct.com voice/fax: (510) 583-1505 cell phone: (510) 421-2284
XML roundtripping - attributes with more than one value
Hi, In Framemaker, when you add more than one value to an attribute of type 'Strings', the values have to be separated by a line break. When you save the file as .xml the values of the attribute are written into one string separated by spaces. No problem there except that when you open the file again in Framemaker the values are also written on one line separated by spaces. Is there any way to reintroduce the line breaks into the attribute value when the file is opened in Framemaker? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
XML roundtripping - attributes with more than one value
Hi, In Framemaker, when you add more than one value to an attribute of type 'Strings', the values have to be separated by a line break. When you save the file as .xml the values of the attribute are written into one string separated by spaces. No problem there except that when you open the file again in Framemaker the values are also written on one line separated by spaces. Is there any way to reintroduce the line breaks into the attribute value when the file is opened in Framemaker? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office
RE: Read/write rules question - retaining markup attribute
Hi Lynne,
Thanks, it works perfectly. The name of the table format and the
attribute value are the same, so no problems there.
The reason I want to do it is that I format the text in the table based
on the type of table it is. It's not that much work to enter this
information - every time I choose to enter the element 'table', I
specify that attribute from a list of choices, then specify the table
format in the next dialog.
The real reasoning behind all this is that I am misusing DITA a bit in
another way: rather than use the 'note' element for notes, I am using
tables. The style guide says that notes should be in a gray box using
italic font. I found the easiest way to do this in Frame is to put the
note in a single cell table. The table format creates the gray
background, I set 'otherprops' to 'note', and then test the 'otherprops'
attribute to format the text.
I do this with a couple of different types of tables, mostly when they
are used for formatting. If anyone has any other suggestions to cope
with this, I'd love to hear them.
Many thanks for your help,
Daniel
Daniel Osborn | Usability Engineer - Technical Writer | TomTom |
[EMAIL PROTECTED] | +31 (0) 20 8500 934 office
-Original Message-
From: Lynne A. Price [mailto:[EMAIL PROTECTED]
Sent: Friday, October 20, 2006 5:56 PM
To: Daniel Osborn; framers@lists.frameusers.com
Subject: Re: Read/write rules question - retaining markup attribute
At 09:13 AM 10/19/2006, Daniel Osborn wrote:
>If you use the is fm property rule to translate a markup attribute
to
>a FrameMaker property, the markup attribute does not also appear as a
>FrameMaker attribute.
>
>My question is, is there a way to do this so that the markup attribute
>does appear as a attribute of the element in Frame. I'd like to keep
>this value so I can test it in the edd and format the text in the table
>accordingly.
Daniel,
Why do you want to do so? The information is stored in both the FM
and
XML representations of the document. As you've described, when you open
an
XML document, FM uses the attribute value to set the table format. When
you
save the FM document to XML, FM will export an attribute.
If you map the XML attribute to an FM attribute, there's no way to
keep
the table format in synch with the attribute value. When you insert a
new
table in a document, the Insert Table dialog box will appear, allowing
you
to select a table format. Short of a plug-in or FrameScript, there's no
way
to ensure that the selected table format is the same as an attribute
value.
Furthermore, you can always change the format of an existing table
within
FM. Again, there's no way to validate that you've changed an attribute
value as well.
Nevertheless, if you really want to do so, you might be able to use
the
rule:
attribute "otherprops" {
is fm property table format;
is fm attribute;
}
If this does work (and I don't have time to test it now), I suspect the
actual table format rather than the attribute value is used on export.
--Lynne
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application
development,
and training
[EMAIL PROTECTED]http://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
___
You are currently subscribed to Framers as [EMAIL PROTECTED]
Send list messages to [EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
or visit
http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com
Send administrative questions to [EMAIL PROTECTED] Visit
http://www.frameusers.com/ for more resources and info.
Read/write rules question - retaining markup attribute
Hi Lynne,
Thanks, it works perfectly. The name of the table format and the
attribute value are the same, so no problems there.
The reason I want to do it is that I format the text in the table based
on the type of table it is. It's not that much work to enter this
information - every time I choose to enter the element 'table', I
specify that attribute from a list of choices, then specify the table
format in the next dialog.
The real reasoning behind all this is that I am misusing DITA a bit in
another way: rather than use the 'note' element for notes, I am using
tables. The style guide says that notes should be in a gray box using
italic font. I found the easiest way to do this in Frame is to put the
note in a single cell table. The table format creates the gray
background, I set 'otherprops' to 'note', and then test the 'otherprops'
attribute to format the text.
I do this with a couple of different types of tables, mostly when they
are used for formatting. If anyone has any other suggestions to cope
with this, I'd love to hear them.
Many thanks for your help,
Daniel
Daniel Osborn | Usability Engineer - Technical Writer | TomTom |
daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office
-Original Message-
From: Lynne A. Price [mailto:lpr...@txstruct.com]
Sent: Friday, October 20, 2006 5:56 PM
To: Daniel Osborn; framers at lists.frameusers.com
Subject: Re: Read/write rules question - retaining markup attribute
At 09:13 AM 10/19/2006, Daniel Osborn wrote:
>If you use the is fm property rule to translate a markup attribute
to
>a FrameMaker property, the markup attribute does not also appear as a
>FrameMaker attribute.
>
>My question is, is there a way to do this so that the markup attribute
>does appear as a attribute of the element in Frame. I'd like to keep
>this value so I can test it in the edd and format the text in the table
>accordingly.
Daniel,
Why do you want to do so? The information is stored in both the FM
and
XML representations of the document. As you've described, when you open
an
XML document, FM uses the attribute value to set the table format. When
you
save the FM document to XML, FM will export an attribute.
If you map the XML attribute to an FM attribute, there's no way to
keep
the table format in synch with the attribute value. When you insert a
new
table in a document, the Insert Table dialog box will appear, allowing
you
to select a table format. Short of a plug-in or FrameScript, there's no
way
to ensure that the selected table format is the same as an attribute
value.
Furthermore, you can always change the format of an existing table
within
FM. Again, there's no way to validate that you've changed an attribute
value as well.
Nevertheless, if you really want to do so, you might be able to use
the
rule:
attribute "otherprops" {
is fm property table format;
is fm attribute;
}
If this does work (and I don't have time to test it now), I suspect the
actual table format rather than the attribute value is used on export.
--Lynne
Lynne A. Price
Text Structure Consulting, Inc.
Specializing in structured FrameMaker consulting, application
development,
and training
lprice at txstruct.comhttp://www.txstruct.com
voice/fax: (510) 583-1505 cell phone: (510) 421-2284
Read/write rules question - retaining markup attribute
Hi, I'm trying to set up the read/write rules for my XML files and have run into a problem. I've cheated a bit with DITA and am using the 'otherprops' attribute of 'table' to store the table format. I'm using this rule: attribute "otherprops" is fm property table format; I set this attribute in Frame and also select the corresponding table format (the same value). When I open the file in FM the attribute value is lost, and the table is formatted correctly. I looked in the structured developers guide and found that this is as designed: If you use the is fm property rule to translate a markup attribute to a FrameMaker property, the markup attribute does not also appear as a FrameMaker attribute. My question is, is there a way to do this so that the markup attribute does appear as a attribute of the element in Frame. I'd like to keep this value so I can test it in the edd and format the text in the table accordingly. I could misuse another attribute and store my value in one, and the FM table format in another. But I'd rather keep the misuse to a minimum. Any ideas? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office
Read/write rules question - retaining markup attribute
Hi, I'm trying to set up the read/write rules for my XML files and have run into a problem. I've cheated a bit with DITA and am using the 'otherprops' attribute of 'table' to store the table format. I'm using this rule: attribute "otherprops" is fm property table format; I set this attribute in Frame and also select the corresponding table format (the same value). When I open the file in FM the attribute value is lost, and the table is formatted correctly. I looked in the structured developers guide and found that this is as designed: If you use the is fm property rule to translate a markup attribute to a FrameMaker property, the markup attribute does not also appear as a FrameMaker attribute. My question is, is there a way to do this so that the markup attribute does appear as a attribute of the element in Frame. I'd like to keep this value so I can test it in the edd and format the text in the table accordingly. I could misuse another attribute and store my value in one, and the FM table format in another. But I'd rather keep the misuse to a minimum. Any ideas? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Read/write rules question - retaining markup attribute
Hi, I'm trying to set up the read/write rules for my XML files and have run into a problem. I've cheated a bit with DITA and am using the 'otherprops' attribute of 'table' to store the table format. I'm using this rule: attribute "otherprops" is fm property table format; I set this attribute in Frame and also select the corresponding table format (the same value). When I open the file in FM the attribute value is lost, and the table is formatted correctly. I looked in the structured developers guide and found that this is as designed: If you use the is fm property rule to translate a markup attribute to a FrameMaker property, the markup attribute does not also appear as a FrameMaker attribute. My question is, is there a way to do this so that the markup attribute does appear as a attribute of the element in Frame. I'd like to keep this value so I can test it in the edd and format the text in the table accordingly. I could misuse another attribute and store my value in one, and the FM table format in another. But I'd rather keep the misuse to a minimum. Any ideas? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Read/write rules question - retaining markup attribute
Hi, I'm trying to set up the read/write rules for my XML files and have run into a problem. I've cheated a bit with DITA and am using the 'otherprops' attribute of 'table' to store the table format. I'm using this rule: attribute "otherprops" is fm property table format; I set this attribute in Frame and also select the corresponding table format (the same value). When I open the file in FM the attribute value is lost, and the table is formatted correctly. I looked in the structured developers guide and found that this is as designed: If you use the is fm property rule to translate a markup attribute to a FrameMaker property, the markup attribute does not also appear as a FrameMaker attribute. My question is, is there a way to do this so that the markup attribute does appear as a attribute of the element in Frame. I'd like to keep this value so I can test it in the edd and format the text in the table accordingly. I could misuse another attribute and store my value in one, and the FM table format in another. But I'd rather keep the misuse to a minimum. Any ideas? Thanks, Daniel Daniel Osborn | Usability Engineer - Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office
Translate FrameMaker book to Hebrew/Arabic and convert to online help
Hi Winfried, One of your solutions: >> Mess around with the registry to get FrameMaker to >> handle right to left languages. Seemed to be only a >> solution for 2 page documents. Why is this only a solution for 2 page documents? And by "mess around with the registry" do you mean set up font substitutions for Hebrew and Arabic? Thanks for sharing what you found out, Daniel -- Date: Wed, 23 Aug 2006 15:07:58 +0200 From: "Reng, Winfried Dr." Subject: RE: Translate FrameMaker book to Hebrew/Arabic and convert to onlinehelp To: Message-ID: <1F5BCB07D8AED54190885844E0EC675D7216F3 at TFSDEMS30002.tycoce.com> Content-Type: text/plain; charset="iso-8859-1" Hi, Thank you all very much for your suggestions. Solutions were: o 2 separate translations: - Convert to HTML, get it translated and convert to HTML Help. - Convert to Word, get it translated and create a PDF. Thus the online help will still be context sensitive. The second translation will cost money but in the era of translation memory systems hopefully not to much. o Convert to XML, get that translated. Then: - Convert the XML to HTML via XSLT. - Convert the XML to PDF via LaTeX. o Convert everything to InDesign. However then I don't have an online help. o Mess around with the registry to get FrameMaker to handle right to left languages. Seemed to be only a solution for 2 page documents. No-one suggested a converter from Word to HTML Help. Best regards Winfried This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
RE: Translate FrameMaker book to Hebrew/Arabic and convert to online help
Hi Winfried, One of your solutions: >> Mess around with the registry to get FrameMaker to >> handle right to left languages. Seemed to be only a >> solution for 2 page documents. Why is this only a solution for 2 page documents? And by "mess around with the registry" do you mean set up font substitutions for Hebrew and Arabic? Thanks for sharing what you found out, Daniel -- Date: Wed, 23 Aug 2006 15:07:58 +0200 From: "Reng, Winfried Dr." <[EMAIL PROTECTED]> Subject: RE: Translate FrameMaker book to Hebrew/Arabic and convert to onlinehelp To: Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="iso-8859-1" Hi, Thank you all very much for your suggestions. Solutions were: o 2 separate translations: - Convert to HTML, get it translated and convert to HTML Help. - Convert to Word, get it translated and create a PDF. Thus the online help will still be context sensitive. The second translation will cost money but in the era of translation memory systems hopefully not to much. o Convert to XML, get that translated. Then: - Convert the XML to HTML via XSLT. - Convert the XML to PDF via LaTeX. o Convert everything to InDesign. However then I don't have an online help. o Mess around with the registry to get FrameMaker to handle right to left languages. Seemed to be only a solution for 2 page documents. No-one suggested a converter from Word to HTML Help. Best regards Winfried This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
CMYK problems
Hi, Thank you to everyone who gave me help and advice with this one. Thought you might be interested to know how it finished. In the job options, I set the Color Management Policies to Convert All Colors to CMYK. I didn't do any post-processing on the pdf file and the printer is very happy with the result. The red is not perfect (M 93 Y 81), but I'm willing to accept that if the printer is happy and the result is good. Thanks, Daniel Original problem: Framemaker 7.2p158 Acrobat Pro 7 Using Quite a Box of Tricks to convert pdf files to CMYK In FM, the colours are defined like this: Black K 100% Red M 90% Y 86% GreyK 30% And I have some text in an .eps image which is defined as K 100%. In the pdf the colours have these values: Black C 75% M 68% Y 67% B 90% Red C 3%M 100% Y 100% GreyC 21% M 16% Y 16% And the black text in the .eps image is C 75% M 69% Y 62% B 75% ... This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
RE: CMYK problems
Hi, Thank you to everyone who gave me help and advice with this one. Thought you might be interested to know how it finished. In the job options, I set the Color Management Policies to Convert All Colors to CMYK. I didn't do any post-processing on the pdf file and the printer is very happy with the result. The red is not perfect (M 93 Y 81), but I'm willing to accept that if the printer is happy and the result is good. Thanks, Daniel Original problem: Framemaker 7.2p158 Acrobat Pro 7 Using Quite a Box of Tricks to convert pdf files to CMYK In FM, the colours are defined like this: Black K 100% Red M 90% Y 86% GreyK 30% And I have some text in an .eps image which is defined as K 100%. In the pdf the colours have these values: Black C 75% M 68% Y 67% B 90% Red C 3%M 100% Y 100% GreyC 21% M 16% Y 16% And the black text in the .eps image is C 75% M 69% Y 62% B 75% ... This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
CMYK problems
Hi Mike, Thank you, changing the setting in the job options solved it. And thanks also for the explanation of the problem for the printer. I also discovered that if I change that setting to "Convert all colours to CMYK", the colours in the file are also ok and the whole file is CMYK. I didn't need to use Quite a Box of Tricks to create a CMYK file, the output from FM was already CMYK. I'm waiting to hear from the printer about whether either of these files is good enough to print. Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office -Original Message- From: Mike Wickham [mailto:mewick...@compuserve.com] Sent: Wednesday, May 17, 2006 3:10 PM To: Daniel Osborn Subject: Re: CMYK problems Daniel, A couple of things to check. In Frame, make sure the color definitions are set to Process and CMYK. In Distiller, check the job option settings: Settings> Edit Adobe PDF Settings. Look on the Color tab and check Color Management Policies. The setting there can cause 4-color black text, instead of plain black. For example, changing "Tag Everything for Color Management" to "Tag Only Images for Color Management" can make the 4-color text go back to plain black. Text must be plain black. If it's four-color, each ink prints on top the other and without absolutely perfect registration (alignment) of the four ink plates, you get text that's black in the middle (where all inks overlap), but with cyan, magenta, and yellow edges peaking out. That's what causes the muddy brown the printer talked about, and makes text look fuzzy rather than crystal clear. Mike Wickham - Original Message - From: "Daniel Osborn" To: Sent: Tuesday, May 16, 2006 12:57 PM Subject: CMYK problems Hi, I have some questions about creating pdf files for a printer. To try and get it right, I'm currently doing the following: 1. Only use cmyk .eps images. 2. Set GetLibraryColorRGBFromCMYK to 'Printing' 3. Save as pdf rather than print to pdf. 4. Convert the resulting pdf to cmyk using Quite a box of tricks. I use save as pdf because I found that the images lost a lot of quality when the pdf was converted to cmyk, although I think this may have been before I started using .eps images. The files I generated have been printed with very good results. Many thanks to everyone on the list who helped me get to this stage when I first had to produce a file for a printer. I'm now delivering to a different printer and they don't like the colours in the pdf. The images are not a problem, it's the colours used for text, thumb tabs and shading in tables. In FM, the colours are defined like this: Black K 100% Red M 90% Y 86% GreyK 30% And I have some text in an .eps image which is defined as K 100%. In the pdf the colours have these values: Black C 75% M 68% Y 67% B 90% Red C 3%M 100% Y 100% GreyC 21% M 16% Y 16% And the black text in the .eps image is C 75% M 69% Y 62% B 75% The printer is saying that the 'black' text will come out as a muddy brown with misregistration issues (not sure what that means) and he is also not happy with the other colours. I used the Output preview tool in Acrobat Pro 7 to get these figures (and so did the printer). I've tried printing to pdf with the same result and also changing GetLibraryColorRGBFromCMYK to None, with the same result. Can anyone help me with this? I can understand that some colours will change slightly but I don't understand why black comes out like this and also why the black in an .eps image has changed so much. I'm also a little confused that the last printer didn't have any problems with the files, at least none that he told me about. I'm using Framemaker 7.2p158. The printer suggested I use FM 6 on the Mac instead... Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as mewickham at compuserve.com. Send list messages to framers at lists.frameusers.com. To unsubscribe send a blank email to framers-unsubscribe at lists.frameusers.com or visit http://lis
RE: CMYK problems
Hi Mike, Thank you, changing the setting in the job options solved it. And thanks also for the explanation of the problem for the printer. I also discovered that if I change that setting to "Convert all colours to CMYK", the colours in the file are also ok and the whole file is CMYK. I didn't need to use Quite a Box of Tricks to create a CMYK file, the output from FM was already CMYK. I'm waiting to hear from the printer about whether either of these files is good enough to print. Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office -Original Message- From: Mike Wickham [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 17, 2006 3:10 PM To: Daniel Osborn Subject: Re: CMYK problems Daniel, A couple of things to check. In Frame, make sure the color definitions are set to Process and CMYK. In Distiller, check the job option settings: Settings> Edit Adobe PDF Settings. Look on the Color tab and check Color Management Policies. The setting there can cause 4-color black text, instead of plain black. For example, changing "Tag Everything for Color Management" to "Tag Only Images for Color Management" can make the 4-color text go back to plain black. Text must be plain black. If it's four-color, each ink prints on top the other and without absolutely perfect registration (alignment) of the four ink plates, you get text that's black in the middle (where all inks overlap), but with cyan, magenta, and yellow edges peaking out. That's what causes the muddy brown the printer talked about, and makes text look fuzzy rather than crystal clear. Mike Wickham - Original Message - From: "Daniel Osborn" <[EMAIL PROTECTED]> To: Sent: Tuesday, May 16, 2006 12:57 PM Subject: CMYK problems Hi, I have some questions about creating pdf files for a printer. To try and get it right, I'm currently doing the following: 1. Only use cmyk .eps images. 2. Set GetLibraryColorRGBFromCMYK to 'Printing' 3. Save as pdf rather than print to pdf. 4. Convert the resulting pdf to cmyk using Quite a box of tricks. I use save as pdf because I found that the images lost a lot of quality when the pdf was converted to cmyk, although I think this may have been before I started using .eps images. The files I generated have been printed with very good results. Many thanks to everyone on the list who helped me get to this stage when I first had to produce a file for a printer. I'm now delivering to a different printer and they don't like the colours in the pdf. The images are not a problem, it's the colours used for text, thumb tabs and shading in tables. In FM, the colours are defined like this: Black K 100% Red M 90% Y 86% GreyK 30% And I have some text in an .eps image which is defined as K 100%. In the pdf the colours have these values: Black C 75% M 68% Y 67% B 90% Red C 3%M 100% Y 100% GreyC 21% M 16% Y 16% And the black text in the .eps image is C 75% M 69% Y 62% B 75% The printer is saying that the 'black' text will come out as a muddy brown with misregistration issues (not sure what that means) and he is also not happy with the other colours. I used the Output preview tool in Acrobat Pro 7 to get these figures (and so did the printer). I've tried printing to pdf with the same result and also changing GetLibraryColorRGBFromCMYK to None, with the same result. Can anyone help me with this? I can understand that some colours will change slightly but I don't understand why black comes out like this and also why the black in an .eps image has changed so much. I'm also a little confused that the last printer didn't have any problems with the files, at least none that he told me about. I'm using Framemaker 7.2p158. The printer suggested I use FM 6 on the Mac instead... Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/mewickham%40c
CMYK problems
Hi, I have some questions about creating pdf files for a printer. To try and get it right, I'm currently doing the following: 1. Only use cmyk .eps images. 2. Set GetLibraryColorRGBFromCMYK to 'Printing' 3. Save as pdf rather than print to pdf. 4. Convert the resulting pdf to cmyk using Quite a box of tricks. I use save as pdf because I found that the images lost a lot of quality when the pdf was converted to cmyk, although I think this may have been before I started using .eps images. The files I generated have been printed with very good results. Many thanks to everyone on the list who helped me get to this stage when I first had to produce a file for a printer. I'm now delivering to a different printer and they don't like the colours in the pdf. The images are not a problem, it's the colours used for text, thumb tabs and shading in tables. In FM, the colours are defined like this: Black K 100% Red M 90% Y 86% GreyK 30% And I have some text in an .eps image which is defined as K 100%. In the pdf the colours have these values: Black C 75% M 68% Y 67% B 90% Red C 3%M 100% Y 100% GreyC 21% M 16% Y 16% And the black text in the .eps image is C 75% M 69% Y 62% B 75% The printer is saying that the 'black' text will come out as a muddy brown with misregistration issues (not sure what that means) and he is also not happy with the other colours. I used the Output preview tool in Acrobat Pro 7 to get these figures (and so did the printer). I've tried printing to pdf with the same result and also changing GetLibraryColorRGBFromCMYK to None, with the same result. Can anyone help me with this? I can understand that some colours will change slightly but I don't understand why black comes out like this and also why the black in an .eps image has changed so much. I'm also a little confused that the last printer didn't have any problems with the files, at least none that he told me about. I'm using Framemaker 7.2p158. The printer suggested I use FM 6 on the Mac instead... Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
CMYK problems
Hi, I have some questions about creating pdf files for a printer. To try and get it right, I'm currently doing the following: 1. Only use cmyk .eps images. 2. Set GetLibraryColorRGBFromCMYK to 'Printing' 3. Save as pdf rather than print to pdf. 4. Convert the resulting pdf to cmyk using Quite a box of tricks. I use save as pdf because I found that the images lost a lot of quality when the pdf was converted to cmyk, although I think this may have been before I started using .eps images. The files I generated have been printed with very good results. Many thanks to everyone on the list who helped me get to this stage when I first had to produce a file for a printer. I'm now delivering to a different printer and they don't like the colours in the pdf. The images are not a problem, it's the colours used for text, thumb tabs and shading in tables. In FM, the colours are defined like this: Black K 100% Red M 90% Y 86% GreyK 30% And I have some text in an .eps image which is defined as K 100%. In the pdf the colours have these values: Black C 75% M 68% Y 67% B 90% Red C 3%M 100% Y 100% GreyC 21% M 16% Y 16% And the black text in the .eps image is C 75% M 69% Y 62% B 75% The printer is saying that the 'black' text will come out as a muddy brown with misregistration issues (not sure what that means) and he is also not happy with the other colours. I used the Output preview tool in Acrobat Pro 7 to get these figures (and so did the printer). I've tried printing to pdf with the same result and also changing GetLibraryColorRGBFromCMYK to None, with the same result. Can anyone help me with this? I can understand that some colours will change slightly but I don't understand why black comes out like this and also why the black in an .eps image has changed so much. I'm also a little confused that the last printer didn't have any problems with the files, at least none that he told me about. I'm using Framemaker 7.2p158. The printer suggested I use FM 6 on the Mac instead... Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Adapting EDD for WebWorks ePublisher Pro 9.1
Hi Framers, I'd like to ask your opinion on a workaround I've just found for using structured Frame with WebWorks ePublisher Pro 9.1 At the moment, I have a problem with WebWorks ePublisher Pro as it doesn't support basing styles on elements. All my formatting is defined in the edd using the format change list. If I were using paragraph formatting in the edd, I could create empty paragraph formats in my FM docs by saying "Automatically create formats on import" at the top of the edd, then use these formats in WebWorks. I've been playing a bit and discovered that it seems like I can create the paragraph formats and continue to use the format change list. I declare each context rule twice (by copying the context rule I was using). In the first instance, I change "Use format change list" to "Use paragraph format". When I import the edd into my documents all the paragraph formats are created and the formatting is correct (based on the format change list). My question is, is this a sensible workaround? I'm not experienced enough with structured Frame or edds to know if this will have any unwanted consequences anywhere or to know what is really happening. There are some things that now don't work, for example, you can't adjust font sizes or indents using "Font size change" or "Move indent". I haven't changed everything yet as I would have to make quite a few changes to the edd (especially concerning lists) and before I do that, I'd like to hear any opinions on this. Many thanks for your help, Daniel This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
Adapting EDD for WebWorks ePublisher Pro 9.1
Hi Framers, I'd like to ask your opinion on a workaround I've just found for using structured Frame with WebWorks ePublisher Pro 9.1 At the moment, I have a problem with WebWorks ePublisher Pro as it doesn't support basing styles on elements. All my formatting is defined in the edd using the format change list. If I were using paragraph formatting in the edd, I could create empty paragraph formats in my FM docs by saying "Automatically create formats on import" at the top of the edd, then use these formats in WebWorks. I've been playing a bit and discovered that it seems like I can create the paragraph formats and continue to use the format change list. I declare each context rule twice (by copying the context rule I was using). In the first instance, I change "Use format change list" to "Use paragraph format". When I import the edd into my documents all the paragraph formats are created and the formatting is correct (based on the format change list). My question is, is this a sensible workaround? I'm not experienced enough with structured Frame or edds to know if this will have any unwanted consequences anywhere or to know what is really happening. There are some things that now don't work, for example, you can't adjust font sizes or indents using "Font size change" or "Move indent". I haven't changed everything yet as I would have to make quite a few changes to the edd (especially concerning lists) and before I do that, I'd like to hear any opinions on this. Many thanks for your help, Daniel This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Problem generating PDFs for the printer - it always comes out as RGB
Thank you all for your suggestions. I've tried to use Colour Chameleon 2.0 and also CMYK PDF Creator, but both say they cannot find or start Distiller. I have Acrobat 7.0 Pro installed - I reinstalled it, just to make sure it was all there; I checked the permissions in the registry and I seem to have the full read/write permissions that the programs require. Is there anything else that I might be doing wrong? Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office -Original Message- From: Bill Swallow [mailto:techcommd...@gmail.com] Sent: Monday, February 06, 2006 9:03 PM To: Daniel Osborn Cc: framers at lists.frameusers.com Subject: Re: Problem generating PDFs for the printer - it always comes out as RGB Welcome to the wonderful world of Windows on PC. ;-) You want this: http://www.pdfstore.com/details.asp?ProdID=215 On 2/6/06, Daniel Osborn wrote: > I'm having a serious problem generating pdfs for the printer. Everything > in my book is rgb, despite the fact the all my images are cmyk and all > colours are specified as cmyk. Even when I tell Distiller to change > everything to cmyk I still get only rgb. -- Bill Swallow HATT List Owner WWP-Users List Owner 42.8162,-73.7736 http://techcommdood.blogspot.com I support Char James-Tanny for STC Secretary. This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
Problem generating PDFs for the printer - it always comes out as RGB
Hi, I'm having a serious problem generating pdfs for the printer. Everything in my book is rgb, despite the fact the all my images are cmyk and all colours are specified as cmyk. Even when I tell Distiller to change everything to cmyk I still get only rgb. Does anyone have any ideas? Framemaker 7.2b144 Acrobat Pro 7.0.0 Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | daniel.osborn at tomtom.com | +31 (0) 20 8500 934 office This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information.
RE: Problem generating PDFs for the printer - it always comes out as RGB
Thank you all for your suggestions. I've tried to use Colour Chameleon 2.0 and also CMYK PDF Creator, but both say they cannot find or start Distiller. I have Acrobat 7.0 Pro installed - I reinstalled it, just to make sure it was all there; I checked the permissions in the registry and I seem to have the full read/write permissions that the programs require. Is there anything else that I might be doing wrong? Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office -Original Message- From: Bill Swallow [mailto:[EMAIL PROTECTED] Sent: Monday, February 06, 2006 9:03 PM To: Daniel Osborn Cc: framers@lists.frameusers.com Subject: Re: Problem generating PDFs for the printer - it always comes out as RGB Welcome to the wonderful world of Windows on PC. ;-) You want this: http://www.pdfstore.com/details.asp?ProdID=215 On 2/6/06, Daniel Osborn <[EMAIL PROTECTED]> wrote: > I'm having a serious problem generating pdfs for the printer. Everything > in my book is rgb, despite the fact the all my images are cmyk and all > colours are specified as cmyk. Even when I tell Distiller to change > everything to cmyk I still get only rgb. -- Bill Swallow HATT List Owner WWP-Users List Owner 42.8162,-73.7736 http://techcommdood.blogspot.com I support Char James-Tanny for STC Secretary. This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
Problem generating PDFs for the printer - it always comes out as RGB
Hi, I'm having a serious problem generating pdfs for the printer. Everything in my book is rgb, despite the fact the all my images are cmyk and all colours are specified as cmyk. Even when I tell Distiller to change everything to cmyk I still get only rgb. Does anyone have any ideas? Framemaker 7.2b144 Acrobat Pro 7.0.0 Thanks, Daniel Daniel Osborn | Technical Writer | TomTom | [EMAIL PROTECTED] | +31 (0) 20 8500 934 office This e-mail message contains information which is confidential and may be privileged. It is intended for use by the addressee only. If you are not the intended addressee, we request that you notify the sender immediately and delete or destroy this e-mail message and any attachment(s), without copying, saving, forwarding, disclosing or using its contents in any other way. TomTom N.V., TomTom International BV or any other company belonging to the TomTom group of companies will not be liable for damage relating to the communication by e-mail of data, documents or any other information. ___ You are currently subscribed to Framers as [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
