Pages: « 1 2 3 4 5 6 7 8 9 10 »
 41 
 on: March 22, 2019, 07:02:29 AM 
Started by PaoloS - Last post by PaoloS
Hi Derek,
thanks for the comprehensive reply.
Trying to completely reset the css file the problem disappears.

I started to exclude half by half the css rules (binary search) to understand what was causing the problem.
Surprisingly, the para tag (most used) had a display: block; set, and removing it the problem is solved....

But removing the "display: block;" rule the paragraphs no longer go on a new line.
In the ctm file customization I tried to insert the NewLineAfterEnd option but without visual effect.

 42 
 on: March 21, 2019, 09:23:22 AM 
Started by jodekirk - Last post by jodekirk
I have XML Comments displaying in tags on view, but they are hidden in Normal View. Is there a setting to display them in Normal View?

Here's the style I have currently:
Code:
$COMMENT {
  display: inline-block;
  color: purple;
  white-space: pre;
}

 43 
 on: March 19, 2019, 03:16:07 PM 
Started by PaoloS - Last post by Derek Read
This is true in general: the larger a document is the slower interactions with that document will be.

However, 110KB is nowhere near what I would consider to be "large". I would say that's pretty small. We have clients that work with multi-MB sized documents. In some cases editing is "slow" but that depends on much more than simply XML file size. As an example, the sample "CamerasInFocus.xml" (that uses the fairly complex journalist.dtd) ships at 8KB. After copying and pasting content in that document to increase overall content size to 1.5MB I see no reduction in authoring interactions other than an increase in save time (which also does a full document validation by default), increasing from less than 1 second (at 8KB) to several seconds (at 1.5MB).

So, here are some things to look at:

The complexity of the document itself and the complexity of the schema (DTD or XSD) can contribute. In other words, a document consisting of one element containing thousands of lines of text will be easier on the software than a document with thousands of elements each containing a small amount of text. A document containing complex validation rules can also slow editing (complexity of the schema). In other words, if the software needs to decide between many elements, attributes, or values when inserting or changing or validating those things vs a simpler schema where there are only a few options editing the latter will be faster. These issues are primarily related to how XMetaL Author uses its "rules checking" feature to stop users from putting a document into an invalid state.

If none of the things below help then the primary strategy in this case would be to reduce document size (if the schema is not the issue or the schema cannot be altered) and then piece together multiple smaller documents when transforming the XML to its final output (if that is necessary).

Additional things that will slow editing include the complexity of the CSS used to render the document in Tags On and Normal view as well as macros that run when various actions take place. The CTM file can also have an effect, primarily if it contains script or if it is configured to render XFT forms with complicated scripting code or display many XFT documents inline in a document.

The "check spelling while typing" feature can also slow editing, so it makes sense to try turning that off, as you have done.

The "bidirectional text" feature (which is off by default) can drastically reduce editing speed, depending on which languages are being rendered, so if you don't need that feature make sure it is off.

You might try a test where you replace your CSS file and CTM file with empty files to see if that helps. If it does help then replace portions of those files until the issue returns to find out what is contributing to the slow down.

Macros that fire frequently (such as On_Update_UI) can slow down document editing, as well as macros that run less frequently but contain complex code, or macros that are relying on some external service to respond (these would typically be found with CMS integrations or systems that help with language such as spelling, grammar, controlled language database, etc).

The rendering of tables in a document can be slow, depending on the table type. HTML tables are auto-sized so they can be slower than CALS to render while users are making changes to content within them. Very large tables in general are slow (all table types). The only solution here is to reduce their size, which typically means breaking large tables into pieces then joining them together during output transformation if the final output requires that.

Note that the issues above generally don't apply to Plain Text view as most of the features mentioned won't function in that view, or if they do they function in a much simpler way.

 44 
 on: March 19, 2019, 10:09:53 AM 
Started by PaoloS - Last post by PaoloS
Users reports that the typing experience is slow with increse of size of document.
With a relative big document (110kb of xml ) some times is very annoing use the editor.

As developer, i checked if there is some macro that running but i found correlations with the problem.

in Options > General > i tried to remove check from "Check spelling while typing" but not resolve the issue.

Binary#: 12.0.0.077
Installer#: 12.0.0238



 45 
 on: March 18, 2019, 02:51:57 PM 
Started by queshaw - Last post by queshaw
Ah. Thank you! I would not have thought to look there. The samples are in %programdata%\SoftQuad\Developer\Samples

 46 
 on: March 18, 2019, 01:23:43 PM 
Started by queshaw - Last post by Derek Read
The developer samples should be listed in the Windows Start menu under an item named XMetaL.

The samples included with XMetaL Author are listed in it's Help menu under Samples, but these simply open an XML sample document that uses those customizations. The actual customization files are installed in the XMetaL Author installation itself.

 47 
 on: March 17, 2019, 03:35:33 PM 
Started by queshaw - Last post by queshaw
That sounds like what I'm looking for. But, I haven't found it among the files installed with XMetaL Developer 12.0. There is no Samples directory below c:\Program Files (x86)\XMetaL 12.0\Developer. Is there a way to get the sample?

 48 
 on: March 15, 2019, 03:49:15 PM 
Started by Roopesh79 - Last post by Derek Read
It does, but the Schematron itself needs to be designed in a very specific way, and the resulting default display output is not that nice to look at.

 49 
 on: March 15, 2019, 03:47:30 PM 
Started by queshaw - Last post by Derek Read
Yes, XMetaL Developer includes a document-level customization called "MiniJournalist" which is a simple DTD and basic CSS, CTM files. Is that the kind of example you are looking for?

XMetaL Author itself includes three sample document-level customizations: Journalist, Meeting Minutes, and Docbook.

The Journalist sample uses a proprietary DTD created around the time DocBook for XML was being initially designed so it looks similar to some degree but it is just meant for demonstration. This customization shows off a large number of APIs through macros, includes some XFT forms, custom toolbars and menus. An XSD version of the DTD is also provided that uses all the same customization files but the XSD for validation and to drive the Element List and Attribute Inspector.

The Meeting Minutes sample is a really strange use for the software but it shows off some interesting functionality, including how to interact with a database.

The Docbook sample uses the 5.0 version of the Docbook standard DTDs. It is just a sample but could be used to build a more robust authoring environment for that schema. It shows off a bunch of APIs similar to the Journalist sample, exposed in this case via the Docbook menu (which itself is added to show how menus can be customized) and includes a demo of XInclude, and functionality for displaying the same document using different CSS styling.

 50 
 on: March 15, 2019, 02:49:49 PM 
Started by olehtine - Last post by Derek Read
Yes, that path looks to be far under any Windows limits (commonly 255).

Hard to say exactly what your issue might be. Perhaps there is some race condition occurring with multiple copies of the software or another process attempting to use files at the same time?

The initial posting suggested the software was hanging (and never opening the file). But it sounds to me like what you are saying is that the file is opened, it just takes longer using one method (there are many ways to open a file in the GUI and via different APIs) vs right clicking and asking Windows Explorer to ask XMetaL Author to open the file.

If you were to move the customization files to the user's local machine (this is the standard method of deployment) that should speed things up (if the issue is the speed of copying the files from the server each time).

I'm not sure what you mean when you mention macros being an issue. Whatever behaviour you are seeing with macros would likely be very specific to what the macro is doing. If you can provide XMetaL Support with some samples they could have a look and possibly make some recommendations.

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