Please note I am subscribed to this list, so it is unnecessary to send a
duplicate post directly to me.
Replying in-line.
On 29/03/2022 23:01, flywire wrote:
> Can you comment in terms of experience formatting code in the guide?
It is unclear what you are asking me to comment on. My experience of
this project goes back to 2010 and beyond, during which time I have
contributed to a number of guides, I am also one of the authors of the
current 7.x guide template.
> I previously commented code colorization should be part of the style running
> any macro behind the scenes. It isn't (ie changing the template does
> nothing).
As explained below, the "Code" style of the 7.x guide template can be
changed to any Font Color the docs team wish it to be.
I am starting to think we might be talking at cross purposes. I am
talking about a style used in the OTT template used to produce our user
guides and I suspect you are referring the styling of code used to
produce the software. These are two entirely different subjects.
Maybe the use of the term "Code" has led to some misunderstanding. Our
user guides do not contain any usable programming code, but where a
guide needs to explain/illustrate something like one or two lines of
Basic code, the guide author uses the "Code" style as defined below.
> If you look through the guides you'll see a lot of inconsistency
> from random processes.
Please cite a few specific examples of where the docs team have
overlooked this apparently endless stream of errors and inconsistencies.
>1. Extension configuration is not specified anywhere
Please explain what you mean by "Extension configuration". It sounds
like a reference to a software OXT extension, which is something the
docs team have no direct control over.
>2. The code style does not color the text, it's done externally or maybe
>using this macro
The 7.x guide template clearly defines the "Code" style:
* Font = Liberation Mono, Regular, 11 pt.
* Font Color = Automatic (ie. Black) with no other effects.
* Area = Light Gray 5
All of those attributes, including Font Color, can be changed in the 7.x
guide template.
>3. The extension also styles text which can conflict with the
>documentation style
So why add an unnecessary possible conflict?
>4. The hotkey description would be better replaced by a link.
What has a "hotkey description" got to do with a documentation template
style?
> The whole process is pretty poor.
I am sure the entire docs team would welcome an explanation of what we
have been doing so "poorly" over the years.
> On top of that, copy/paste doesn't work
> in pdf -
The issue being discussed here is about the styling used in the 7.x
guide template used to produce the original Open Document Text files for
our user guides.
> https://listarchives.libreoffice.org/global/documentation/2022/msg00295.html
The link you cite one of your own posts complaining about what you
perceive to be defects in the way LibreOffice creates PDF files from ODF
files. This is matter you should raise with the developer and/or QA
teams, since the docs team have no control over this.
Sorry but your macro proposal would provide no additional benefit to the
production of our user guides, but would add unnecessary complications
for our authors.
> On Wed, Mar 30, 2022 at 12:39 AM Dave Barton wrote:
>
>> Why has this unnecessary macro operation been added to chapter 2 of the
>> "Producing LibreOffice User Guides"?
>> We already have a perfectly good "Code" style in the 7.2x template. If
>> the docs team feel the style needs changing/improving then let's simply
>> agree on a revision of the template, not by adding more complexity to
>> documentation production.
>>
>
--
To unsubscribe e-mail to: documentation+unsubscr...@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/documentation/
Privacy Policy: https://www.documentfoundation.org/privacy
