Building All Output Formats for RTEMS Docs
Christian Mauderer
christian.mauderer at embedded-brains.de
Mon Nov 7 22:32:51 UTC 2016
----- Ursprüngliche Mail -----
> Von: "Chris Johns" <chrisj at rtems.org>
> An: "Christian Mauderer" <christian.mauderer at embedded-brains.de>
> CC: "RTEMS Devel" <devel at rtems.org>
> Gesendet: Montag, 7. November 2016 23:23:42
> Betreff: Re: Building All Output Formats for RTEMS Docs
> On 07/11/2016 19:27, Christian Mauderer wrote:
>>
>> with your patch that removes lato and inconsolata, there are now fewer packages
>> necessary on Arch. It is now not longer necessary to install the quite large
>> texlive-fontsextra (nearly 700MB). Beneath that, the pygmentize packet has
>> somehow been lost in my original patch to the README.
>>
>> I appended a patch that will remove texlive-fontsextra from the Arch Linux
>> section of the README and add pygmentize again.
>>
>
> I have taken a closer look at the finished output and it is not as good
> which is why the fonts were used before. I am now wondering if we detect
> the better fonts and use them when present.
>
> If we move to generate docs based on the lowest common denominator we
> may end up with docs that are not the best we could have that reflects
> on the project.
>
> Chris
Hi Chris,
it would be nice if there are some good visible warnings if fallback packages are used. Otherwise it might be hard for someone building the documentation to find out why the output looks different.
As an alternative it could be nice to have a configuration option like '--no-fallback' that prevents the system from using any fallback fonts or packages. This would allow to find all missing packages for the optimal output.
Kind regards
Christian
--
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list