Pages: « 1 2 3 4 5 6 7 8 9 10
 91 
 on: August 22, 2016, 12:58:33 AM 
Started by maciej_m - Last post by maciej_m
Hi,

As a new user of XMetal 11 and DITA OT 2.2, I am struggling with some issues. Some of them are easy to solve, but other need time to investigate. That's why I decided to ask professionals :)

Well, I would like to print id attribute from ditamap file in each header of publication?

Regards

 92 
 on: August 22, 2016, 12:43:35 AM 
Started by bjorn - Last post by bjorn
Hi!

I'm about to customize the XMetaL90.ini but I can't find information for all the options in the http://xmetal.com/webhelp/en/xmetaldeveloper/cg/7.0/cg.html#Configuration%20variables. Some of the options seems self explanatory, but I just want to confirm there actions.

  • parser_lax_empty_content = false
  • image_path = C:\XMetaL\images\
  • document_path = C:\XMetaL\docs\
  • new_dlg_rules_path = C:\XMetaL\dtds\

Thanks!

BR
Bjørn

 93 
 on: August 19, 2016, 01:52:39 AM 
Started by ChrisTMH - Last post by ChrisTMH
The DITA specification uses the OASIS CALS spec for tables (at least that is the only table type in DITA that supports widths in the markup). This table model is very different from HTML, which is what most people are familiar with (if they are familiar with any kind of table model).

Unlike HTML, you cannot directly specify an overall table size with CALS and have the columns expand to fill it. Or you can (using proportional sizes), but if you do then you have no control over the exact size of the table. If you want to control the exact size of the table then you need to use fixed width columns. You can then use the pgwide attribute on the table element itself if you want to change the behaviour of the overall table size:

Quote from: DITA Specification for <table> element
In DITA tables, in place of the @expanse attribute used by other DITA elements, the @pgwide attribute is used in order to conform to the OASIS Exchange Table Model. The @pgwide attribute has a similar semantic (1=page width; 0=resize to galley or column).

If you want a table to be a specific size you set all columns using fixed width units (cm, in, etc) and not * (proportional). If you have one or more columns in a table set using proportional width then it will fill in any remaining space after any fixed width columns have been set.

Note that the deliverable "XMetaL Enhanced PDF via RenderX XEP" does not respect the pgwide attribute, so if you want PDF output with tables that are not full width you will either need to modify it or use another deliverable that outputs PDF.

Table widths or formatting of any kind in XML is tending away from the concept of separating content from style. For the two main table models in use with XML (HTML and CALS) their markup tends to "pollute" the rest of the content (my opinion). Producing different outputs from this kind of markup can be troublesome (or at least extra work) if the widths, or other table settings that are essentially style, are important to you. You may end up needing to produce a duplicate table with slightly different settings for different outputs for DITA, if you produce both PDF and HTML. Conditional text could be used to do that, or you might prefer to alter how the DITA Open Toolkit handles them.

An alternative is to set things up with another attribute (in DITA this might be @outputclass) that tells the DITA OT to lay out the entire table according to a standard set of stylist rules (which might be different for different outputs) but this would also require the DITA OT to be modified to recognize whatever values you choose for that and produce the desired table layout.

Ok, all understood. The issue I have, however, is that if I set the column widths of my table to an absolute value, in my case now 40mm for each, then this is not shown on the PDF, only on the XMetaL view. Why does this happen?


 94 
 on: August 16, 2016, 01:16:01 PM 
Started by ChrisTMH - Last post by Derek Read
The DITA specification uses the OASIS CALS spec for tables (at least that is the only table type in DITA that supports widths in the markup). This table model is very different from HTML, which is what most people are familiar with (if they are familiar with any kind of table model).

Unlike HTML, you cannot directly specify an overall table size with CALS and have the columns expand to fill it. Or you can (using proportional sizes), but if you do then you have no control over the exact size of the table. If you want to control the exact size of the table then you need to use fixed width columns. You can then use the pgwide attribute on the table element itself if you want to change the behaviour of the overall table size:

Quote from: DITA Specification for <table> element
In DITA tables, in place of the @expanse attribute used by other DITA elements, the @pgwide attribute is used in order to conform to the OASIS Exchange Table Model. The @pgwide attribute has a similar semantic (1=page width; 0=resize to galley or column).

If you want a table to be a specific size you set all columns using fixed width units (cm, in, etc) and not * (proportional). If you have one or more columns in a table set using proportional width then it will fill in any remaining space after any fixed width columns have been set.

Note that the deliverable "XMetaL Enhanced PDF via RenderX XEP" does not respect the pgwide attribute, so if you want PDF output with tables that are not full width you will either need to modify it or use another deliverable that outputs PDF.

Table widths or formatting of any kind in XML is tending away from the concept of separating content from style. For the two main table models in use with XML (HTML and CALS) their markup tends to "pollute" the rest of the content (my opinion). Producing different outputs from this kind of markup can be troublesome (or at least extra work) if the widths, or other table settings that are essentially style, are important to you. You may end up needing to produce a duplicate table with slightly different settings for different outputs for DITA, if you produce both PDF and HTML. Conditional text could be used to do that, or you might prefer to alter how the DITA Open Toolkit handles them.

An alternative is to set things up with another attribute (in DITA this might be @outputclass) that tells the DITA OT to lay out the entire table according to a standard set of stylist rules (which might be different for different outputs) but this would also require the DITA OT to be modified to recognize whatever values you choose for that and produce the desired table layout.

 95 
 on: August 16, 2016, 01:33:05 AM 
Started by ChrisTMH - Last post by ChrisTMH
Hi again,

What has lead me to having this issue is there being, it seems, no way to set the size of a table overall. To get around this, a user specifies the width of the table either by scale or by absolute size, which is then calculated and divided up amongst the columns, with each column width being set, resulting in the width of the table being as expected by the user.

The issue I'm having is that whenever I specify and absolute width, in my case with millimeters, the widths are only changed in the XMetaL view but not in PDF view. I've also tried this using "Book via RenderX" for output, no change.

Any advice on this?

 96 
 on: August 09, 2016, 12:03:03 PM 
Started by megl - Last post by Derek Read
Best to check with DocZone support as they are driving the system.

 97 
 on: August 09, 2016, 09:35:54 AM 
Started by megl - Last post by megl
Windows 7, Author Enterprise 10.0.0.074, DocZone Docato 4.9.2

Error:

Editor applet is not initialized. Please check browser settings and/or restart your browser.

I have set Java, Pop-up and Cookies in the browser settings. Are there other browser settings that I need to be able to edit in XMetaL from DocZone?

 98 
 on: August 05, 2016, 05:38:37 AM 
Started by ChrisTMH - Last post by ChrisTMH
Despite the misleading name ("Enhanced") I don't think development of the deliverable named "XMetaL Enhanced PDF via RenderX XEP" has kept up with that of the rest of the DITA Open Toolkit, so it will have limitations like this. This deliverable was originally included to overcome a large number of limitations in the early versions of the DITA Open Toolkit deliverables (adding support for Bookmaps, indexes, sorting, various elements, etc. that the DITA OT versions of PDF output did not handle), however, it has since fallen behind as development on the DITA OT versions of PDF has progressed.

If you use one of the other PDF deliverables they are likely to give you what you want and are being actively developed (Book via RenderX for example).



Thanks for the help. Yes, the output is as expected when using "Book via RenderX". So, once I found the source files for this output (org.dita.pdf2), I compared the implementation with my default implementation. I discovered that, by default, there are no table borders (obvious now I know). In our default implementation, not sure if this was done by us in the past, but there was some code that put borders in even with colsep or rowsep set to 0, so I simply commented these out and it now works fine.

Thanks again.

 99 
 on: August 04, 2016, 01:59:00 PM 
Started by ChrisTMH - Last post by Derek Read
Despite the misleading name ("Enhanced") I don't think development of the deliverable named "XMetaL Enhanced PDF via RenderX XEP" has kept up with that of the rest of the DITA Open Toolkit, so it will have limitations like this. This deliverable was originally included to overcome a large number of limitations in the early versions of the DITA Open Toolkit deliverables (adding support for Bookmaps, indexes, sorting, various elements, etc. that the DITA OT versions of PDF output did not handle), however, it has since fallen behind as development on the DITA OT versions of PDF has progressed.

If you use one of the other PDF deliverables they are likely to give you what you want and are being actively developed (Book via RenderX for example).


 100 
 on: August 04, 2016, 05:02:26 AM 
Started by ChrisTMH - Last post by ChrisTMH
DITA version 1.2
XMetaL version 10.0.0.074

If I have inserted and table and set the attribute values "colsep" and "rowsep" for the "tgroup" element both to 0 (off), then the following occurs:

  • In the XMetaL view, all internal borders are correctly displayed with dashed lines to indicate no borders
  • When the PDF is generated, all internal borders still remain

So, there are no internal borders when processed with CSS, but there are when transformed into PDF.

Is this a known glitch, or am I simply overlooking something?

Cheers

Pages: « 1 2 3 4 5 6 7 8 9 10
email us