Bug 41737 - LOCALHELP: Indentation and colors missing in BASIC code examples
Summary: LOCALHELP: Indentation and colors missing in BASIC code examples
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Documentation (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low enhancement
Assignee: Andras Timar
URL:
Whiteboard: target:4.0.0 target:4.1.0
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-12 17:47 UTC by Jim Avera
Modified: 2014-03-27 22:08 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screen capture showing missing indentation in code examples (156.09 KB, image/png)
2011-10-12 17:54 UTC, Jim Avera
Details
screen-shot showing double-spacing of new colorized examples (112.64 KB, image/png)
2014-03-14 19:01 UTC, Jim Avera
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Avera 2011-10-12 17:47:30 UTC
There is no indentation in code examples in online documentation.

Presumably the indentation is lost somewhere in the tool chain which generates the final form.

For example, run calc and do

Help->LibreOffice Help
Select "Libreoffice Basic" in drop-down box in upper left
Search for "if statement"

Scroll to example code at the end of the page. The indentation, which presumably was there in the original documentation format, has been lost.
Comment 1 Jim Avera 2011-10-12 17:54:17 UTC
Created attachment 52280 [details]
Screen capture showing missing indentation in code examples
Comment 2 Rainer Bielefeld Retired 2011-10-12 23:33:34 UTC
I agree that indents would make the code more understandable, but IMHO we never had indents in the Help (I did some samples back until OOo 1.1.4)
Comment 3 Rainer Bielefeld Retired 2011-10-12 23:38:16 UTC
From the beginning, inherited from OOo.

Additionally using the text colors from IDE would be fine.

WIKIHELP also is affected, but I believe formatting will be transferred?

@David
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 4 David Nelson 2011-10-12 23:47:33 UTC
This sounds like an enormous job. There must be a large number of examples in the help that need re-formatting like this. I'll take custody of the bug and report it to the English documentation team, but I'm not able to commit to doing all the work myself. This will definitely have to be a team effort.
Comment 5 Björn Michaelsen 2011-12-23 13:24:28 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Comment 6 Andras Timar 2012-09-13 15:46:05 UTC
Now we have a student (Bence Babati) who works actively on one part of this bug, so let me give an update and explain my understanding on this bug.

We can of course do anything we want in help source xhp files. But it is not the way to go. We do not want change manually a lot of source code, and we do not want to create work for help translators. It would be better not to change xhp files at all.

1. Syntax highlight in local help. This is what Bence is working on. In help compiler, where we clone the xml tree of xhp files, we can intercept, and do the syntax highlight build time. We can tokenize Basic source code lines and put the tokens between <item type="foobar"> </item> tags, where foobar can be keyword, literal, number, etc. Actual coloring will be done by help .css files.

2. Syntax highlight in wikihelp. Probably the easiest would be to use a syntax highlighter extension in MediaWiki, and convert <paragraph role="code"> paragraphs in Basic help into <source language="oobas"> ... </source>. Ideally we should detect consecutive code paragraphs and put them into one <source> block.

3. Indentation. It never existed. We need to insert spaces manually to xhp files, but in order to avoid extra l10n work, leading spaces should be cropped/reinserted by l10n tools.
Comment 7 Not Assigned 2012-09-13 20:59:09 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9302520ff445d9789859f501b8bd6bc32c300e26

enable indentation of Basic source code in help fdo#41737



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 8 Not Assigned 2012-09-13 20:59:40 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/help/commit/?id=9fdd8ca77efc6bf1c4b69021f0168ee84d83378f

enable indentation of Basic source code in help fdo#41737



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 9 Not Assigned 2012-09-13 21:00:00 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/help/commit/?id=40989785363cf0238ed7228b7ca662fab75fc9ac

enable syntax highlight of Basic source code in wikihelp fdo#41737



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 10 Andras Timar 2012-11-24 18:37:41 UTC
Just to give you an update:
In help source files in master branch all Basic examples are indented and marked up so, that help to wiki converter can preserve indentation and apply the syntax highligh. In offline help currently only indentation is present, work in in progress on syntax highlighting.
Comment 11 Not Assigned 2013-02-13 09:38:31 UTC
Andras Timar committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=67b8c0339e90c42dca402a925a624fce67f8ea5c

fdo#41737 syntax highlighting of Basic code examples in offline help



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 12 Andras Timar 2013-02-13 09:40:59 UTC
With David Vastag's work, finally the offline help features Basic code highlighter, too. It will be in LibreOffice 4.1.
Comment 13 Jim Avera 2014-03-14 18:59:59 UTC
The indenting and colorization of BASIC code examples is wonderful.  Thank you David, Andras and any others who helped make it happen.

However there's a lingering glitch - they are all double-spaced...
Please see attached screen-shot (observed in 4.2.1 and 4.3alpha)

(Apologies if double-spacing was intentional.  IMO it makes it hard to read longer examples because you have to scroll to see all the code)
Comment 14 Jim Avera 2014-03-14 19:01:00 UTC
Created attachment 95819 [details]
screen-shot showing double-spacing of new colorized examples
Comment 15 Andras Timar 2014-03-14 20:37:20 UTC
(In reply to comment #14)
> Created attachment 95819 [details]
> screen-shot showing double-spacing of new colorized examples

This a different issue, BTW I'm working on right now. I think it is related to bug 75040. Let's leave this bug alone, i.e. RESOLVED FIXED.
Comment 16 Jim Avera 2014-03-27 22:08:47 UTC
Ok.  I tested a 3-25-2014 4.3alpha build (which should include the fixes for bug 75040) and the double-spacing problem is gone.   Thanks!