headers
Hussein Shafie | 1 Jun 2011 11:55
Favicon

Re: Generate IDs in element templates

Mariusz Idzikowski wrote:
>  
> Is there a way to add automatic IDs to elements generated from custom
> element templates when generateIds="true" in the configuration? It seems
> that element templates do not take this setting into account.
>  

Sorry but there is currently no way to achieve what you want.

Option generateIds="true" only applies to automatically created
elements. This option does not apply to user-defined elements templates.

However, *dynamic* user-defined elements templates (automatically
generating an ID would be of course supported by this feature) is an
often-requested feature. Therefore we'll seriously consider implementing
it in a future release. It's too late for v4.9.1 which should be
released in a couple of weeks.

--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
Permalink | Reply | 2 comments |
headers
Hussein Shafie | 1 Jun 2011 12:22
Favicon

Re: about XMLmind some display error when edit Chinese

roc.zhang wrote:
>  
> I am found some less question,  when I edit chinese/english Jobcard
> using XMLmind4.9 with our XDOC . 
>  
> 1.when [Preference]==>[General]=>[Locale] set  for "Chinese" ,the
> editing line do not Break when chang display area, but set for "english"
> display is OK. 

The Locale you have chosen has nothing to do with this problem. Lines
written in Chinese do not wrap because, in Chinese, unlike English,
there is no whitespace between words.

You can safely set the Locale to any value you want. This will not
influence the behavior of XMLmind XML Editor.

> Please below screen copy:
>  

Fortunately, the problem you have is very easy to fix.

Procedure:

[1] Please select menu item "Options|Preferences".

[2] Then, in the "Preferences" dialog box, select the "View" section.

[3] Here please check the "Wrap words wider than available space" checkbox.

This option, which slightly modifies the behavior of word wrap in both
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Taylor | 3 Jun 2011 14:48
Picon

docbook5 custom configuration not working

Hi

I am having a rather frustrating time trying to get a simple
customisation to DocBook5 working (6 hours so far and counting).

I have the following in a file called (on OS X):

.../Library/Application
Support/XMLmind/XMLEditor4/addon/cy_custom/customize.xxe

<?xml version="1.0" encoding="UTF-8"?>
<configuration mimeType="application/x-docbook-5+xml" name="DocBook v5+"
               xmlns="http://www.xmlmind.com/xmleditor/schema/configuration"
               xmlns:xslt="http://www.w3.org/1999/XSL/Transform"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xs="http://www.w3.org/2001/XMLSchema"
               xmlns:xlink="http://www.w3.org/1999/xlink"
               xmlns:xi="http://www.w3.org/2001/XInclude"
               xmlns:svg="http://www.w3.org/2000/svg"
               xmlns:html="http://www.w3.org/1999/xhtml"
               xmlns:db="http://docbook.org/ns/docbook"

xmlns:cfg="http://www.xmlmind.com/xmleditor/schema/configuration">
  <include location="xxe-config:docbook5/docbook5.xxe"/>

  <elementTemplate name="requirement" selectable="true">

<db:formalpara><db:title/><db:para/><db:procedure><db:title/><db:step><db:para/></db:step></db:procedure></db:formalpara>
  </elementTemplate>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hussein Shafie | 3 Jun 2011 17:31
Favicon

Re: docbook5 custom configuration not working

===================================================================
IMPORTANT! Starting from XXE v4.9, you must disable the quick start
cache before customizing the configurations by hand.

See
http://www.xmlmind.com/xmleditor/_distrib/doc/help/com.xmlmind.guiutil.PreferencesEditorDialog.html#cacheOptions
===================================================================

On 06/03/2011 02:48 PM, Richard Taylor wrote:
> 
> I am having a rather frustrating time trying to get a simple
> customisation to DocBook5 working (6 hours so far and counting).
> 

Really sorry for that.

> I have the following in a file called (on OS X):
> 
> .../Library/Application
> Support/XMLmind/XMLEditor4/addon/cy_custom/customize.xxe

customize.xxe is a name reserved for a customization which is not
associated to a specific document type. We recommend to rename this file
to docbook5.xxe.

> 
> <?xml version="1.0" encoding="UTF-8"?>
> <configuration mimeType="application/x-docbook-5+xml" name="DocBook v5+"
>                xmlns="http://www.xmlmind.com/xmleditor/schema/configuration"
>                xmlns:xslt="http://www.w3.org/1999/XSL/Transform"
(Continue reading)

Permalink | Reply | 2 comments |
headers
Richard Taylor | 3 Jun 2011 20:55
Picon

Re: docbook5 custom configuration not working

Thanks for the detailed response.

Turning off the quick start cache makes all the difference! May be it
should be noted in the documentation :-)

The 'add custom element templates' tool looks very useful, but I was
trying to write a customisation file that I could roll out to all my
users. Is it possible to copy the template created through the tool so
that they can be distributed?

We are just starting to learn how to get the most out of XXE, it is a
real up hill struggle to convince the authors to use a different tool
and the more customisation that I can give them the more likely it is
they will see the benefits.

Thanks

Richard

On 03/06/2011 16:31, Hussein Shafie wrote:
> ===================================================================
> IMPORTANT! Starting from XXE v4.9, you must disable the quick start
> cache before customizing the configurations by hand.
> 
> See
> http://www.xmlmind.com/xmleditor/_distrib/doc/help/com.xmlmind.guiutil.PreferencesEditorDialog.html#cacheOptions
> ===================================================================
> 
> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hussein Shafie | 4 Jun 2011 10:59
Favicon

Re: docbook5 custom configuration not working

On 06/03/2011 08:55 PM, Richard Taylor wrote:
> Thanks for the detailed response.
> 
> Turning off the quick start cache makes all the difference! May be it
> should be noted in the documentation :-)

Well, this is already clearly stated in the online help, but it seems
that this is not enough. We'll document that in the "Configuration and
Deployment" guide too.

> 
> The 'add custom element templates' tool looks very useful, but I was
> trying to write a customisation file that I could roll out to all my
> users. Is it possible to copy the template created through the tool so
> that they can be distributed?

Sure. Please take a look at the configuration files called "conf"
automatically generated in

$HOME/Library/Application
Support/XMLmind/XMLEditor4/custom/MANGLED_CONFIG_NAME_HERE/

directories.

> 
> We are just starting to learn how to get the most out of XXE, it is a
> real up hill struggle to convince the authors to use a different tool
> and the more customisation that I can give them the more likely it is
> they will see the benefits.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe Nobili | 7 Jun 2011 17:57
Favicon

OLinking does not work since XXE 4.8.0 (FOP issue)

Dear M. Shafie,

It seems that we are facing a serious issue with OLinking in DocBook PDF 
output since XXE 4.8.0.  It took us quite a bit of  time to locate the 
problem, since our DocBook customization has not changed for years.

Now, we have found it and  it seems related to apache FOP:

When we attempt to use OLinks since XXE 4.8.0, instead of generating 
appropriate PDF links, FOP generate link to the current PDF document 
using a wrong PDF link fragment. Clicking on the link attempt to open a 
Web browser.... The problem disappears if we comment the following line 
out (excerpt from our XXE docbook layer):

<parameter name="fop1.extensions">1</parameter>

Needless to say, we absolutely need these extensions to get the side 
navigational table of contents in our PDF outputs... and we use OLinks 
quite a lot.

Did we miss something, and if not, is there anything that could be done 
to restore the correct FOP behavior in XXE 4.8 or later ?
Many thanks for your help.
Philippe.

 
--
XMLmind XML Editor Support List
xmleditor-support <at> xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
(Continue reading)

Permalink | Reply | 10 comments |
headers
Hussein Shafie | 7 Jun 2011 19:54
Favicon

Re: OLinking does not work since XXE 4.8.0 (FOP issue)

On 06/07/2011 05:57 PM, Philippe Nobili wrote:
> 
> It seems that we are facing a serious issue with OLinking in DocBook PDF 
> output since XXE 4.8.0.  It took us quite a bit of  time to locate the 
> problem, since our DocBook customization has not changed for years.
> 
> Now, we have found it and  it seems related to apache FOP:
> 
> When we attempt to use OLinks since XXE 4.8.0, instead of generating 
> appropriate PDF links, FOP generate link to the current PDF document 
> using a wrong PDF link fragment. Clicking on the link attempt to open a 
> Web browser.... The problem disappears if we comment the following line 
> out (excerpt from our XXE docbook layer):
> 
> <parameter name="fop1.extensions">1</parameter>
> 
> Needless to say, we absolutely need these extensions to get the side 
> navigational table of contents in our PDF outputs... and we use OLinks 
> quite a lot.
> 
> Did we miss something, 

No.

> and if not, is there anything that could be done 
> to restore the correct FOP behavior in XXE 4.8 or later ?

If it's really a bug in FOP v1[*], that is, a regression from FOP v0.9,
then the only solutions are:
(Continue reading)

Permalink | Reply | 9 comments |
headers
nobili, philippe | 8 Jun 2011 08:43
Favicon

Re: OLinking does not work since XXE 4.8.0 (FOP issue)

Many thanks for your answer.

It seems that we have the same issue with other PDF readers; so this is unlikely to be a bug in Acroread.

We are left with the two other possibilitie (might also be a combination of both...), that is either a bug in
FOP 1 or in Docbook FO XSL.

For the later, I guess we can have some clues when looking at the intermediate FO file with and without using
the incriminated FOP extensions.

Meanwhile, how difficult would it be (and can we do this ourselves ?) To backport FOP 0.9 to XXE 4.8+ and build
an XXE FOP 0.9 addon ?

Many thanks for your help,
Philippe.

PS: The fact that this does not work with XEP was indeed one of the reasons for which we decided to stay with
FOP, despite a couple of limitations.

----- Message d'origine -----
De : Hussein Shafie [mailto:hussein <at> xmlmind.com]
Envoyé : Tuesday, June 07, 2011 07:54 PM
À : nobili, philippe
Cc : 'xmleditor-support <at> xmlmind.com' <xmleditor-support <at> xmlmind.com>
Objet : Re: [XXE] OLinking does not work since XXE 4.8.0 (FOP issue)

On 06/07/2011 05:57 PM, Philippe Nobili wrote:
> 
> It seems that we are facing a serious issue with OLinking in DocBook PDF 
> output since XXE 4.8.0.  It took us quite a bit of  time to locate the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe Nobili | 8 Jun 2011 09:57
Favicon

Re: OLinking does not work since XXE 4.8.0 (FOP issue)


>> and if not, is there anything that could be done
>> to restore the correct FOP behavior in XXE 4.8 or later ?
> If it's really a bug in FOP v1[*], that is, a regression from FOP v0.9,
> then the only solutions are:
>
> [a] Report the bug to the FOP dev team and wait for the next release of FOP.
>
> [b] Fix the bug in FOP v1 and contribute the bug fix to the FOP dev team.
>
> [c] Backport FOP v0.9 to XXE v4.8+.
>
>
M. Shafie,

After some additional tests, it seems that the problem lies somewhere 
within the DocBook 1.76 XSL (used since XXE 4.8.0).
It might be either a bug entirely in DocBook XSL or a bad interaction 
with FOP 1.x (or both ??)

  If we replace the DocBook XSL 1.76 by  the DocBook XSL 1.75 shipped 
with XXE 4.7.0, OLinking works fine again in XXE 4.8.0+, as it did with 
prior  XXE releases.

So we are wondering what would be the best way according to you to 
handle this from then on ? (since we cannot just stick to XXE 4.7.0 and 
wish to stay relatively up to date):

Shall we just downgrade the XSL delivered with XXE 4.8.+ for the time 
being and wait for the bug to be fixed in a subsequent DocBook XSL release ?
(Continue reading)

Permalink | Reply | 7 comments |

Gmane