Hi, Clayton,
Some good news and a little bad news, interspersed below:
ccornell - OpenOffice.org wrote:
Quick take:
There would seem to be at least four possibilities for Wiki links:
1) to dated page
2) to current page [better]
3) to anchor in document [what I was thinking of]
4) to footnote with displayed hyperlink [for printing]
5) open a new Writer window, showing the newly-converted Wiki page
[well, I can dream, can't I?]
The nice part is that most of these can be done by a post-processing
routine in Basic. I am still straining my brain, trying to find a good
way, from the UI point of view, to do both (2) and (3) at the same
spot. Do the anchor points survive the conversion process? (I.e., can
(3) be done at all? Button call to embedded macro, with link texts as
parameters?)
We can experiment with a chapter of the Basic Guide and see what can be
done. Anchor points? I'm not sure. We are not using Anchors like
suggested by Karl: http://en.wikipedia.org/wiki/Template:Anchor There
really are no other Anchors to speak of coming from the Wiki source. Any
in-document anchors would have to be added in post-processing.
Or have I missed the point here?
No, you haven't. The anchor points are supposed to be the headings. But
the very bad news is that those "oldid" links don't preserve enough
information for me to do either (2) or (3). That would have to be
tweaked in the Collection extension. Definitely should be.
On reading the doc vs. reading the Wiki, I find reading the doc, in
Writer, much more convenient, and I doubt I am alone in this. (Having
a scrollable TOC only one click away, in the Navigator, is wonderful.
So is the page flow. A Wiki is great for quick look-ups, but for
reading an entire document? PITA.) Hence, I would like to see the
links preserved in the .odt form, especially the external links
(mostly to the API).
Links at this point - the API links - are not preserved at all. The
export from the Wiki converts the API links to preformatted text only.
Any links from the Basic Guide back to the API I've inserted manually.
This was quite a time consuming process to do this manually... something
like this:
- identify the IDL link
- find the corresponding IDL link in the Wiki
- copy the link
- add a hyperlink in the ODT and paste the link
- repeat for each IDL reference.
This is a bit of a large task for the Basic Guide.. imagine the
Developer's guide. If we want ot include the IDL links in the ODT/PDF,
then we really do need to find a way to simplify the process of
connecting up the links.
Thanks for all the hard work.
The IDL linking is done by a custom written Wiki extension that is
non-standard, and thus not supported by the Collections extension. I'm
not sure that we can easily tweak the extension to handle the linking in
the export.
If the Collection extension has a tag table, we're golden. (Well, if you
can write the language, or I can learn to.)
If not, I can still manage. All I should have to do (in Basic) is look
for "com.sun.star" that's /not/ inside an example. The stuff on the
front of the link is constant (I think). This should work for both the
BG and the DG.
I'll take a crack at the code shortly. Never worked with hyperlink
elements, but how hard can they be? (ROFL).
BTW: that IDL extension doesn't seem to show on the Version page,
although the tags it adds do show. Or have I missed something?
If you would like code to deal with all (or some) of the links, I'll
need a couple of pointers to existing raw refs as input, plus what
they should look like as output. The finding and transforming should
be fairly easy.
The raw refs in the Wiki? They are simply the com.sun.whatever wrapped
with an <idl> tag (or <idlm> etc depending on the type of IDL link).
When exported to ODT, they are all given the style "Preformatted" and
look the same as any other preformatted text (eg code snippets).
Misc. good news:
1) First scan complete, all little problems fixed on the Wiki.
2) Suspect Basic example works fine. ("Private" really does mean
private. It's only Dim that defaults to "Public".)
3) I swear I'm going to rewrite and reorganize the "Text Cursor"
section. I had a real knock-down, drag-out battle with the things. There
is no need for other people to have to call them, Text Cursers. But I
doubt I'll get to it in the immediate time-frame.
--
T. J. Frazier
Melbourne, FL
(TJFrazier on OO.o)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org
For additional commands, e-mail: dev-h...@documentation.openoffice.org
