You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Cassandra Targett (JIRA)" <ji...@apache.org> on 2017/05/03 22:27:04 UTC

[jira] [Commented] (SOLR-10296) Convert existing Ref Guide and post-conversion cleanup

    [ https://issues.apache.org/jira/browse/SOLR-10296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15995805#comment-15995805 ] 

Cassandra Targett commented on SOLR-10296:
------------------------------------------

To add to the list, so I don't forget. There are 2 pages in Confluence that use the {{excerpt}} macro and 3 places that use the {{excerpt-include}} macro to pull in the section from one of the other pages. The fact that these contain shared content is lost during the conversion.

The pages are:

* https://cwiki.apache.org/confluence/display/solr/Collection-Specific+Tools (collection-specific-tools.adoc) has an excerpt that is pulled into https://cwiki.apache.org/confluence/display/solr/Core-Specific+Tools (core-specific-tools.adoc) and https://cwiki.apache.org/confluence/display/solr/Using+the+Solr+Administration+User+Interface (using-the-solr-administration-user-interface.adoc)
** These pages have an additional problem, which is that the content is mostly links to other pages, and during conversion those are turned into hard-coded links back to Confluence. This might actually be coming from the export from Confluence, but it really doesn't matter where it comes from, they'll need to be fixed.
* https://cwiki.apache.org/confluence/display/solr/Field+Type+Definitions+and+Properties (field-type-definitions-and-properties.adoc) has an excerpt that is pulled into https://cwiki.apache.org/confluence/display/solr/Defining+Fields (defining-fields.adoc)

There are a couple options for resolution IMO:

* Ignore the problem for now. Content is duplicated across pages, but these two cases aren't really that onerous.
* Start an "inclusion library" of small bits of content that isn't a standalone page, but is designed to be pulled into other pages when they are built as HTML and PDF. I want to start doing this eventually, but hoped to avoid it until we got everything all set up and stabilized.

The right solution might be a mix of both - ignore it for now, and hopefully soon introduce the inclusion library in a more thoughtful way.

> Convert existing Ref Guide and post-conversion cleanup
> ------------------------------------------------------
>
>                 Key: SOLR-10296
>                 URL: https://issues.apache.org/jira/browse/SOLR-10296
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: documentation
>            Reporter: Cassandra Targett
>
> We have developed several tools and scripts for converting the Ref Guide out of Confluence which get us most of the way to a fully converted set of pages. However, we already know that there are several issues that could not be automated.
> From https://github.com/ctargett/refguide-asciidoc-poc/issues/27, we have this list:
> * The conversion process will insert TODOs for several items that we thought might be problematic during conversion; these need to be reviewed and resolved. Some of these items are also covered in the below topics.
> * Block elements in tables. The current version of the PDF creation tool we are using does not handle those properly (see https://github.com/ctargett/refguide-asciidoc-poc/issues/13). In some cases, we should remove the table entirely and present the content in a new way (using, most often, [labled lists|http://asciidoctor.org/docs/user-manual/#labeled-list] instead).
> * Review and (usually) remove huge Tables of Contents from the top of pages. The current design of the online version will automatically create a TOC for the page, we don't need another one and in some cases this TOC was hand-created so can't be removed via conversion.
> * Non-image attachments. Some SVG files will be converted to images, but they should not be treated as images.
> * Failed link conversions. Despite my best attempts, many dummy URLs are treated by Confluence as real URLs (meaning, dummy URLs like {{http://<host>:<port>/solr}} are coded in Confluence's XHTML with <a> tags). These will be converted as URLs but will throw errors during the conversion process. In some cases, the URLs aren't just these example URLs but are indicative of a real problem that needs to be resolved.
> * Spurious <br/> tags. Some API pages have a list of available calls structured as a list but without being a real ordered or unordered list. These will convert badly. The issue https://github.com/ctargett/refguide-asciidoc-poc/issues/31 has a list of pages where this might be a problem.
> * Appropriate Lead Paragraphs. The stylesheet for HTML pages will make the first paragraph of every HTML page a slightly larger font, by way of introduction. In many cases, the first paragraph is not really ready for that sort of treatment and should be revised to be a more succinct introduction to the feature or further contents of the page.
> More problems may be added to this issue as items that specifically need to be cleaned up.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org