[
https://issues.apache.org/jira/browse/SOLR-10934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16226061#comment-16226061
]
Hoss Man commented on SOLR-10934:
---------------------------------
I think we'll have to abandon any plans of running a robust link checker on the
PDF -- or any "single page" output format using the master
{{SolrRefGuide-all.adoc}} file. The metadata we need to be confident that
links/anchors are going where we expect just doesn't exist at that point.
What we _might_ want to consider, is refactoring our build.xml, so that the
same {{<asciidoctor:convert/>}} task options use to generate the PDF, could
also be used to generate a bare bones version of the html-site -- ie: not using
jekyll, just using raw asciidoctor with the "html5" output option. Then we
could (in theory) run the same HTML link checking code we currently have
against that output dir -- just for the purpose of checking the links, not with
any plan to ever publish it.
That way, we could have something like {{ant precommit}} fail if there are any
broken links in the ref-guide -- using entirely ivy managed dependencies, w/o
requiring a local install of ruby/jekyll.
> create a link+anchor checker for the ref-guide PDF using PDFBox
> ---------------------------------------------------------------
>
> Key: SOLR-10934
> URL: https://issues.apache.org/jira/browse/SOLR-10934
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
> Reporter: Hoss Man
> Attachments: SOLR-10934.patch
>
>
> We currently have CheckLinksAndAnchors.java which is automatically run
> against the ref-guide HTML as part of the build to use JSoup to find bad
> links/anchors that asciidoctor doesn't complain about -- but not everyone
> does/can build the HTML version of the ref-guide sincif we can e it requires
> manually installing jekyll.
> The PDF build only requires things installed by ivy (via JRuby) and we
> already have some PDFBox based code in ReducePDFSize.java that operates on
> this PDF every time it's run -- so if we can find a way to do similar checks
> using the PDFBox API we could catch these broken links faster.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
