General XMetaL Discussion
brad_deteau May 27, 2010 at 10:07 pm
XMetaL v4.6 – Preserve place in doc when switching to browser preview?May 27, 2010 at 10:07 pmParticipants 2Replies 3Last Activity 12 years, 8 months ago
Is there a way to preserve your place in the document when you switch to browser preview?
For example: I am working in the middle of a 20-page document in tags-on view. When I go to browser preview, I want to be on the line I was working on … not the top of the document. Every time I switch, I have to scroll to the page I want to preview.
Please don't reply with workarounds. I know all of them.
I'm looking for a “Preserve place in doc when switching views” option.Derek Read May 27, 2010 at 10:09 pm
Reply to: XMetaL v4.6 – Preserve place in doc when switching to browser preview?May 27, 2010 at 10:09 pm
The simple answer is no. The document is being loaded into Internet Explorer in this view so it is as if you saved your XML, did whatever transformation on it that is being done and then opened the resulting file in IE (outside of XMetaL or inside the behavior is going to be the same).brad_deteau May 27, 2010 at 10:21 pm
Reply to: XMetaL v4.6 – Preserve place in doc when switching to browser preview?May 27, 2010 at 10:21 pm
Do you agree this would be a nice feature, if your team could figure out how to do it?Derek Read May 28, 2010 at 12:02 am
Reply to: XMetaL v4.6 – Preserve place in doc when switching to browser preview?May 28, 2010 at 12:02 am
Because the scrollbar position in the editing views does not have any relationship with what will be displayed in the embedded copy of IE in Browser Preview we can't simply tell IE to scroll down the same distance. That might get you close, but only if the output is virtually identical to how the XML is styled for editing. Even something as simple as being in TagsOn vs Normal is going to mess that up because the tags take up room that isn't normally going to be in any output.
People (people that customize the product) are free to set up Browser Preview to produce literally any output format. Even if you are producing HTML or PDF (probably the two most common outputs) with output content that is very similar to the XML being edited any styling differences (font sizes, line spacing, etc) will throw things off.
The one output format I can think of that might allow this to work would be HTML because it is possible to reference a portion of an HTML document using the “name” attribute on an element. A few things would need to be done (and work) for this to always take you to the right spot:
1) IE supports addresses in the form filename.html#somevalue and will scroll to the portion of the document containing in the HTML source. I'm not sure an embedded copy of IE will support this type of address however. If it doesn't, and only a full-blown copy of IE (with its full UI displayed) could be configured to render the preview instead (we have alternate APIs that help with that).
2) The transformation process that is configured for your customization would need to insert into the HTML. This means altering the XSLT (or whatever else is doing the transformation if XSLT is not being used).
3) Some indicator of the current position in the document would probably need to be stored or figured out before the transformation occurs so that the address passed in #1 could be properly created. In combination with #2 I think this might best be done by inserting a PI at the author's current selection and then designing the XSLT to trigger on that and insert an at that same position in the HTML (or perhaps nearby depending on what the HTML ultimately looks like, it may be that the portion of the XML you have selected is actually dumped and not included in the output at all for example).
If what is being previewed is another output format, like PDF, it might be possible to inject a bookmark into the file, but then you are dependent on the PDF viewer being used to support that and I'm not sure how to tell any particular PDF viewer to open to a particular bookmark (needs research). I have no idea what the solution might be for other output formats if you transform to something else.
So, basically what I'm saying here is that because this is very dependent on the output itself I think it probably makes the most sense to try to address it as part of any customization work.
- You must be logged in to reply to this topic.