Pages: « 1 2 3 4 5 6 7 8 9 10 »
 81 
 on: March 27, 2019, 02:52:59 PM 
Started by tom_w - Last post by Derek Read
I'm not sure I completely understand, but in Plain Text view if you click on the line number (left edge of the screen) does it do what you are expecting?

 82 
 on: March 27, 2019, 11:36:09 AM 
Started by tom_w - Last post by tom_w
XMetaL Author Enterprise 13.0

I am viewing and editing in Plain Text and I would like to have the active line
highlighted so I can see it highlighted when multitasking in a multimonitor
environment. Some of the lines are more than 2 monitors across. So this would
highlight the line where my cursor is, or where it last appeared before I
had to switch to a different app.  I am not permitted to edit the schema, at least not at this time.



I searched the forum and other help resources. Thank you for your time.

 83 
 on: March 26, 2019, 12:29:57 PM 
Started by PaoloS - Last post by Derek Read
Drawing borders around or having a background-color on very large elements (elements that take up multiple screens) can reduce the editing speed.

Sorry I missed that one. I have had quite a fast computer for a few years now so these issues are very much reduced for me and I have to perform fairly extreme stress tests to see them. In my case the element has to span about 25 screens before I start to notice this issue.

If you are drawing a white border then I suspect you must also have a different background-color set for some parent element. If that element commonly spans multiple screens then that could be contributing.

The colour itself does not matter.

 84 
 on: March 26, 2019, 12:25:15 PM 
Started by jodekirk - Last post by Derek Read
By design XML comments are not visible in Normal view.
Neither XMetaL Author nor XMAX can be configured to show XML comments in Normal view.

 85 
 on: March 22, 2019, 08:13:33 AM 
Started by PaoloS - Last post by PaoloS
Update:

It looks like the problem of the display:block; rule occurs only if there are associated margin-top or margin-bottom rules

 
If i use as workaround the rule es. border-top: 7px solid white; instead margin-top:7px; the issue is reduced

 86 
 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.

 87 
 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;
}

 88 
 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.

 89 
 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



 90 
 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

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