[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: XyWrite's future - NB 10 or something different?
- Subject: Re: XyWrite's future - NB 10 or something different?
- From: Russell Urquhart russurquhart1@xxxxxxxx
- Date: Sun, 08 Mar 2015 10:56:45 -0500
Hi Kari,
I feel your pain as i was in the almost same situation 2 years ago.
My company uses xml sourced documents, editting them with XMetal and a smaller version of Oxygen. I
had always used Xywrite to edit the xml source due to Xywrites speed and functionality, and I never
had to use a mouse, only using keystrokes!
As I would very often have to edit large xml documents (Not my call, that's how they were stored in
the RCS), and there is a need to work 'within' the xml structure, i.e. you need tools that have some
awareness of the DTD/Schema of the file you are working on, or at least work nimbly within the
element structures. While Xywrite was never intended to work with XML files, and possibly it could
be extended via XPL to handle it, there was nothing I could do at that moment. (And it appeared that
no one else was doing what i was doing with Xy to edit xml files.)
On Sat, Mar 07, 2015 at 04:56:04PM +0200, Kari Eveli wrote:
>
> Let's face it: DOS XyWrite is badly dated. New word-processing
> applications and modern editors are very good. New hardware has made the
> Xy speed advantage a non-issue. DOS XyWrite is crippled by its memory
> architecture, it would need a rewrite and a port to 64-bit. And, indeed,
> it has one, albeit a very complex and specialized, namely NotaBene 10. I
> tried this recently, and found that it is a very capable and sleek
> program. But still, it is not for everyone. It is a good academic
> word-processing program for humanities scholars (of a certain affinity,
> namely biblical scholars, etc.), not a general-purpose editor like DOS
> XyWrite or NB 3's main editor component. I was lost in a myriad of
> features that I have no use for. And there are reasons not to use it in
> the academic world, too, as becomes apparent in what follows.
I think to be fair, NB kind of always had this slant. I started with NB 3 before i was encouraghed
to look at Xy 3 & 4, and i recall trying to convince people to use NB, but there were just some
things that they didn't need, etc. It was always Xy/Nb's performance and functionality, as compared
to word processors of the day, that, imo, made it stand out.
>
> This outburst
> (http://osdir.com/ml/text.tei.general/2006-02/msg00085.html) is somewhat
> disparaging, but sadly I find that the conclusion has some truth in it:
> ">/Up until now she's been using Nota Bene/
> I fear sudden transition from Nota Bene to Oxygen might result in terminal
> shock. And I don't mean static discharge from the keyboard.
> [...]
Oxygen, as well as tools like Xmetal, are a differnt type of tool as compared to Xy or any standard
text editor/processor.
> So it is suggested that the solution is XML and an editor like OXygen,
> which is indeed capable of many things, even editing XML in a
> word-processing mode.
> http://www.oxygenxml.com/xml_author/wysiwyg_xml_editor_structured_editing.html
> This editor is used by big publishing houses and academic organizations
> that have switched to XML-based document systems. The price tag is
> steep, and the product is perhaps too powerful for many users.
> There are free alternatives that can edit XML, normal text editors like
> Notepad++ and free XML editors like foxe
> (http://www.firstobject.com/dn_editor.htm), which gives the opportunity
> to edit individual content nodes without messing around with the XML
> codes.
I've played a little with Notepadd++, a lot of people i work with swear by it. Foxe is new to me, i
might have to look at that. I think the issue for any of these such tools, as opposed to Xy/Nb text
processor, is that there needs to be a mechanism to parse or recognize the structure of the xml file
via its' DTD or schema. (Actually there are library's like libxslt that can be called from within a
text app that can validate a given xml file. This is a solution for some, and incomplete solution
for others.
> Most of us are on 64-bit systems which do not handle 16-bit applications
> at all on the operating system level. Xy should move to 64-bit. I find
> myself editing Xy files with modern editors like EditPad. While this is
> feasible, they are not as efficient with complex formatting and editing.
AFAIK, the NB developers have licensed the Xy engine and are using it, in the direction they are
going, for NB. Depedning on the audience and the number of users they have, i don't know if they
would be able to offer a Xy version standalone, for a 64-bit version. Someone could PROBABLY compile
a version internally, but then i would think you might have the issue that their license may not
cover that. I don't know, this is just a guess on my part.
Also, as far as XML formatting goes, usually formatting like italic, or bold, are usually a function
of the element assigned and what that outputs to. Same with alignment, bulleted items, page breaks,
etc. These are element assignments in the xml.
> There is a place for a simple 64-bit XyWrite editor. It could be perhaps
> be extracted from NB10, if the NotaBene company would release the source
> code of the basic editor component (not the NB-specific frills of it),
> but I doubt they be willing to try this. Nevertheless, this could be a
> smart move: open-source projects flourish and can be a boon to a small
> developer. If this does not happen, then there is the general
> open-source editor community.
Some years back on this list, there was a discussion that there existed a C-source version of Xy4,
and that some people on the list had seen it or had it. At the time i suggested that we ought to
examine looking at the C source and trying to get that our to a group of open source developers, in
an attempt to better address, not only current bugs, but to try and move Xy to the future. I was
told that releasing this source out to the open source community may have litigous consequences, and
that even if it did not, it would proabably be hard to get people to develop Xy from the C source.
While the latter is probably true, i still believe that, having the source, we could have fixed
some things. Who knows! Maybe things are different now, but someone DOES have the source for xy 4
(or at least Signature) maybe that will turn up?
> I have a dream of a Xy3 and Xy4-compatible
> simple editor with collapsible formatting and perhaps with
> user-definable formatting codes, so one could change «MBRV» to «MDIT»,
> «MD+IT» or perhaps to at will. It should have full customizable Xy
> keyboard file support. The simple Xy3 codes have been very useful when
> converting to other formats for desktop publishing and the Net. In my
> opinion, XyWrite should have been developed into a back-end editor of
> desktop publishing and content production systems instead of trying to
> be a generalist word processor. NB 10 is not generalist, but it is too
> refined to be of much use to the general Xy crowd (if there still is
> such a thing).
For me, the things that i liked about Xy: speed, ascii text only, extensive functionality, extensive
scripting capability, extensive keyboard mapping, never having to leave the kayboard for commands,
etc have all been addressed, as well as xml editting tools, syntax folding, cross platform support,
and free price tag, with Vim/Gvim. I use the xmledit plugin with GVim to edit my documents. As i've
said in the past, people ought to check this out.
Also, an area where, in my opinion, Xy could still be used for current documents is to look into
Markdown, and ASCIIDoc as ascii based markup protocols that convert, then, to either html, pdf, or
docbook.
Also the pandoc utility takes these ascii markup files to and from various formats, namely Word docx
files, LaTex, Html, etc.
Good luck and let me know if i can help!
I've been there!
Russ