If it's any help, I would suggest looking at how SymPy does its PDF
documentation. We have a few adjustments to the Sphinx defaults to make
things work (although it's honestly not that much, mainly just using XeTeX
for Unicode support).
https://github.com/sympy/sympy/blob/master/doc/Makefile
One
Hi all!
Happy to say this:
*1. We drop pdf builds in CI, the release process and the Docker image, but
keep support in the code base.*
*2. Rohit volunteered to maintain the pdf build, so if he (or another
person we know and trust to receive artifacts from and distribute them)
wants to send PRs
On Mon, May 23, 2022, at 10:34, Ralf Gommers wrote:
> I'm not so interested in the detailed discussion later on in this thread to
> be honest. Let me propose a simple solution that should make everyone happy:
> 1. We drop pdf builds in CI, the release process and the Docker image, but
> keep
Furthermore, the PDF docs of numpy (and maybe scipy) can be stripped to a
separate project and put on a separate release cycle, not necessarily
tracking the releases.
On Mon, May 23, 2022 at 10:37 AM Ralf Gommers
wrote:
>
>
> On Mon, May 23, 2022 at 10:21 AM Lev Maximov
> wrote:
>
>> What do
On Mon, May 23, 2022 at 10:21 AM Lev Maximov wrote:
> What do you guys think of the chm format ("windows help")? This offline
> documentation format is shipped with all python releases (eg
> https://www.python.org/downloads/release/python-3913/).
> It is simple to build from a hierarchy of html
This goalpost is moving too much. I am not drawing parallels with SciPy to
make a point on NumPy. I am using it to give another data point where we
did exactly the same thing with zero backlash providing its usage
frequency. You might think they are separate but the user base is
surprisingly
The argument is about why one should use PDF on a mobile device. I am
not even going to bother with the argument. The world moved on. See
any app on your device.
Lets agree to not talk about the world here a bit, user profiles vary. I
have three browser apps true, but also a bunch of PDF
On Mon, May 23, 2022 at 2:00 PM Rohit Goswami
wrote:
> The contents are nonresponsive. No tool can fix a native responsiveness
> issues. I am familiar with those tools. The questions is why work so hard
> when you have the HTML already?
>
> I'm afraid I don't understand this argument. It is
The contents are nonresponsive. No tool can fix a native
responsiveness issues. I am familiar with those tools. The questions
is why work so hard when you have the HTML already?
I'm afraid I don't understand this argument. It is true that PDFs are
not responsive without software assistance,
On Mon, May 23, 2022 at 11:12 AM Rohit Goswami
wrote:
> I am unaware of the state of the SciPy documentation at the time it was
> dropped. However, many of these arguments do not seem to apply to the NumPy
> documentation hosted at https://numpy.org/doc/.
>
They were almost identical, same
I am unaware of the state of the SciPy documentation at the time it was
dropped. However, many of these arguments do not seem to apply to the
NumPy documentation hosted at https://numpy.org/doc/.
The typography is \\subsubpar (as a TeX person should say) and just an
eyesore, this actually
As the person initiated the PDF drop in SciPy, I'd give my reasoning for
why it bugged me in the first place
- The typography is \subsubpar (as a TeX person should say) and just an
eyesore, this actually matters a lot more than you would assume and
unreadable in mobile without constant zooming
What do you guys think of the chm format ("windows help")? This offline
documentation format is shipped with all python releases (eg
https://www.python.org/downloads/release/python-3913/).
It is simple to build from a hierarchy of html files, it is downloadable,
searchable, bookmarkable, has
On Mon, May 23, 2022 at 6:51 AM Matti Picus wrote:
>
> On 23/5/22 01:51, Rohit Goswami wrote:
> >
> > Being very hard to read should not be reason enough to stop generating
> > them. In places with little to no internet connectivity often the PDF
> > documentation is invaluable.
> >
> > I
On Mon, May 23, 2022 at 1:31 AM Stephan Hoyer wrote:
> On Sun, May 22, 2022 at 3:52 PM Rohit Goswami
> wrote:
>
>> Being very hard to read should not be reason enough to stop generating
>> them. In places with little to no internet connectivity often the PDF
>> documentation is invaluable.
>>
>
On 23/5/22 01:51, Rohit Goswami wrote:
Being very hard to read should not be reason enough to stop generating
them. In places with little to no internet connectivity often the PDF
documentation is invaluable.
I personally use the PDF documentation both on my phone and e-reader
when I
On Sun, May 22, 2022 at 4:54 PM Rohit Goswami
wrote:
> Being very hard to read should not be reason enough to stop generating
> them. In places with little to no internet connectivity often the PDF
> documentation is invaluable.
>
> I personally use the PDF documentation both on my phone and
The HTML docs can also be downloaded for offline use.
HTML documentation isn't easy to navigate on anything other than a
laptop / tablet. It also makes it confusing when there isn't an internet
connection because of the external links. Also it is hard (subjectively)
to read in order.
Also
On Sun, May 22, 2022 at 3:52 PM Rohit Goswami
wrote:
> Being very hard to read should not be reason enough to stop generating
> them. In places with little to no internet connectivity often the PDF
> documentation is invaluable.
>
The HTML docs can also be downloaded for offline use.
Perhaps
Being very hard to read should not be reason enough to stop generating
them. In places with little to no internet connectivity often the PDF
documentation is invaluable.
I personally use the PDF documentation both on my phone and e-reader
when I travel simply because it is more accessible and
+1 let’s drop the PDF docs. They are already very hard to read.
On Sun, May 22, 2022 at 1:06 PM Charles R Harris
wrote:
> Hi All,
>
> This is a proposal to drop the generation of pdf documentation and only
> generate the html version. This is a one way change due to the difficulty
>
21 matches
Mail list logo