<azonenberg>
it has both a PDF and HTML copy of the documentation, both manually generated on my machine and snapshotted (i.e. it's not part of the automated deploy process, i'm just adding artifacts to the website repo)
<azonenberg>
there's no download link since we dont have a binary release, and i can probably make the code link a little more obvious
<azonenberg>
yes htlatex was adding a lot of curly braces. I don't know the root cause of them, since i wasn't seeing such issues with pdflatex
<azonenberg>
it still generated output just fine
<d1b2>
<hansemro> Generates output, but make4ht returns 1, so cmake fails
<azonenberg>
oh interesting
<azonenberg>
If you have a bit of time to try and figure out why it's inserting those curly braces, please dig into it
<azonenberg>
I looked at the tex source code and nothing seemed obviously off
<d1b2>
<hansemro> Commenting out \thickhline in section-bert-drivers.tex seems to resolve these errors
<d1b2>
<hansemro> I am including only the bert section to isolate the issue
<d1b2>
<hansemro> You can try this yourself: cd scopehal-apps/build/doc sed -i -E "s/(\\\thickhline)/%\1/g" ../../doc/section*.tex sed -i -E "s/(\\\thinhline)/%\1/g" ../../doc/section*.tex make
<d1b2>
<hansemro> Isolated to two commands
<azonenberg>
interesting
<azonenberg>
ok i'll investigate. in the meantime can you send a PR against the CI scripts and scopehal-docs to include the missing packages?
<d1b2>
<hansemro> Issue is with Xhline, so not sure how we should proceed
<d1b2>
<hansemro> replacing it is one option
<azonenberg>
The table lines in general are not rendering in the HTML anyway
<azonenberg>
if you look i have some macros in the top level defined differently for pdf vs html
<azonenberg>
to size images to "mostly page width"
<azonenberg>
it might be worth making one that is a thickhline in PDF and nothing in HTML, then we can just use CSS to theme the table borders?
<azonenberg>
then just globally replace thickhline with this command
<_whitenotifier-f>
[scopehal-apps] hansemro 01703c5 - Add missing make4ht and dvipng utils to ubuntu CI
<_whitenotifier-f>
[scopehal-apps] azonenberg 59ee7dd - Merge pull request #617 from hansemro/ci-add-make4ht-ubuntu Add missing make4ht and dvipng utils to ubuntu CI
<d1b2>
<azonenberg> @hansemro also when you get a chance can you send a pr to scopehal-docs updating the install instructions to include those packages?
<d1b2>
<hansemro> Sure, I'll get around it once I find a suitable replacement for Xhline
<d1b2>
<hansemro> make4ht documents use of CSS, which does seem like a viable method for drawing table rules/lines
<d1b2>
<johnsel> html docs look terrible though looking at the source
<azonenberg>
johnsel: lol, yeah that's generated from latex then converted to html. one option i am exploring is to see if we can convert those files to markdown via pandoc
<azonenberg>
then use jekyll to template them the same as with the rest of the site
<azonenberg>
so they'll be themed right and probably less ugly html
<d1b2>
<johnsel> (note that I taught html/css amongst others as mentor for years) so I can tell you all the ways this is bad lol
<azonenberg>
But hey, any browsable docs are better than none :)
<d1b2>
<johnsel> I think that approach is much better and will likely produce something reasonable
<d1b2>
<johnsel> I knew you were going to say that and no I would prefer nothing
<d1b2>
<johnsel> lol
<azonenberg>
So there is no direct latex to one-file-per-section markdown possible
<azonenberg>
If we did it, it'd be make4ht tex -> multifile html then pandoc html ->markdown for each file individually
<azonenberg>
then jekyll markdown back to html
<d1b2>
<johnsel> I can look into it for a bit if you'd like, I have had to deal with stuff like this many times before
<azonenberg>
Sure lol. i mean long term i'd like to have scopehal-docs as a submodule of the website repo
<d1b2>
<johnsel> you're free to do it differently then if you prefer but I think I can get an output that would be on par with the average reasonable web documentation
<azonenberg>
and script all of this, and pdf generation, in jekyll
<azonenberg>
so we can just periodically update scopehal-docs submodule in the website repo and get all of the HTML and PDF generated
<d1b2>
<johnsel> there's a reason we find AI research in the form of a PDF paper and github code repo
<azonenberg>
rather than having to generate manually and commit generated files
<d1b2>
<johnsel> and maybe a separate website lol
<d1b2>
<johnsel> yeah, that'd be ideal
<d1b2>
<johnsel> I think/hope I can get that with a markdown step in between
<azonenberg>
Sounds good, just collaborate with hansem who is tweaking the latex stuff now
<azonenberg>
make sure you dont step on each other
<d1b2>
<johnsel> btw you say convert the html to markdown
<d1b2>
<johnsel> I would start from the latex
<juh>
^
<d1b2>
<johnsel> you've already lost all the structure in the html by this output
<azonenberg>
So i considered that
<d1b2>
<johnsel> that's what makes it bad mostly
<azonenberg>
My understanding is that pandoc, at least in the version that debian bullseye ships, does not support going from a single latex file to split multi-file HTML
<azonenberg>
that is a fairly recently added feature
<azonenberg>
i suppose i could install updated pandoc from source but i want to avoid dragging too many dependencies around if we can avoid it
<azonenberg>
which is preventing latest Ceph from compiling on it
<d1b2>
<johnsel> I can look into it
<d1b2>
<johnsel> I know what I'd want the markdown/html to contain too for accessibility reasons etc
<azonenberg>
yeah we have no alt text on any of the images yet
<azonenberg>
that was something i was going to worry about way down the road once we had things compiled well
<azonenberg>
(also alt text in particular is a low priority for me given the nature of the project, it's unlikely someone who can't see well would be able to use it anyway)
<azonenberg>
letting them read about it would be nice, but it's unlikely we will make a user of the software unable to access documentation by not having alt text
<d1b2>
<johnsel> I mean that's the lowest priority accesibility wise
<d1b2>
<johnsel> but also accessibility == google parseable
<d1b2>
<johnsel> and just general ux
<azonenberg>
well yes. i'm not opposed to it, for sure
<azonenberg>
but yeah its lower priority vs making it clean and readable and compile properly
<d1b2>
<johnsel> I mean you say that but good luck keeping a list of links to answer FAQs with Introduction.html#x3-30001.1
<azonenberg>
Lol. yes
<azonenberg>
that is indeed a nightmare
<azonenberg>
this was literally the result of me spending an hour playing with build scripts trying to get something a browser would render at all :p
<d1b2>
<johnsel> it's fine, I did this professionally I'll give it a quick look and tell you what I think we should do and what the advantages are
<d1b2>
<johnsel> I'm no stickler for things being done my way necessarily
<azonenberg>
Yeah. ultimately i want it to look pretty, be usable, and be maintainable
<azonenberg>
And keep the website and pdf docs synced as automatically as possible
<azonenberg>
From a single set of source files
<azonenberg>
(I'm also not 100% opposed to a different format as source vs LaTeX, as long as we can make pretty PDFs from it in the end)
<d1b2>
<johnsel> yes ofcourse, ideally we have one source for all, we'd have to see markdown as a source is not better
<azonenberg>
And as long as someone else does the conversion :p
<d1b2>
<johnsel> I think there are better paths from markdown to html and to pdf automagically, but ofcourse you lose the latex spark
<azonenberg>
Yeah for sure
<d1b2>
<johnsel> latex produces a document
<d1b2>
<johnsel> the rest just present information
<d1b2>
<johnsel> lol
<d1b2>
<johnsel> maybe we can do markdown -> latex -> pdf
<d1b2>
<johnsel> but you said you'd like it to be done by jekyl?
<azonenberg>
like i said idgaf what the flow is as long as we have a single set of sourecs
<azonenberg>
We are currently hosting the website on github pages using jekyll. that is also not a hard requirement, it's what was easy for me to set up in an hour
<d1b2>
<johnsel> ah ok I think current pdfs are nice
<d1b2>
<johnsel> it'd be nice to keep them this way
<azonenberg>
Yeah
<azonenberg>
So if you can do latex -> ??? -> HTML better than we are now, i'm all for it
<d1b2>
<johnsel> I suspect markdown -> latex -> pdf will allow the current workflow to stay with the exception that markdown becomes primary source
<azonenberg>
Yep, that could work
<d1b2>
<johnsel> and markdown -> html is basically solved
<d1b2>
<johnsel> just have to do latex -> markdown properly once
<azonenberg>
yeah jekyll does that fine
<azonenberg>
(and well i dont know how good markdown -> latex is for ongoing pdf builds)
<d1b2>
<johnsel> yeah jekyll, readthedocs, there are many different ways to do it with more or less functionality automatically available
<azonenberg>
yeah jekyll is just what github pages deploys by default
<d1b2>
<johnsel> we may be able to template the latex as a jekyll document
<azonenberg>
i am not opposed to e.g. self hosting the site longer term
<d1b2>
<johnsel> if not jekyl some other template parsing engine
<azonenberg>
i already have infrastructure for that
<azonenberg>
but i do want it to be static and as free of scripting, client and server side, as possible
<azonenberg>
i.e. it should work with no JS clientside, and pages should be compiled when we update content to static HTML rather than being PHP/ruby/python/whatever that runs every request
<d1b2>
<johnsel> yeah it should be 100% functional without js
<juh>
*catching up* johnsel speaks my language!
<d1b2>
<johnsel> I also see no direct reason to have any js at all at this point
<azonenberg>
Me too
<azonenberg>
i made a point of picking a jekyll theme that didnt use any
<d1b2>
<johnsel> this I know haha
<azonenberg>
Anyway, you guys can do what you do best and make the docs pretty :p
<azonenberg>
all i know how to do is write technical content lol
<azonenberg>
at $dayjob i write reports that look ugly as sin and our docs team makes them pretty for the customers :p
<d1b2>
<johnsel> ah yes I see you appreciate our input
<d1b2>
<johnsel> we're like your unpaid docs/support team is what you are saying?
<azonenberg>
Lol
<azonenberg>
Yeah and i'm your unpaid software engineering team :D
<d1b2>
<johnsel> yeah that was what I was going to say next
<d1b2>
<johnsel> don't worry about it you're my unpaid scope GUI writer
<azonenberg>
lol
<azonenberg>
Anyway yeah, if anyone wants to work on contributing *content* to the docs at some point that is also one of the big blockers to a formal release
<azonenberg>
having something like 100 filters with no documentation whatsoever isn't a great look
<azonenberg>
i remember the other day i was scrolling through the latex source for the filter documentation and I was alphabetically at the D's, but halfway through the document
<azonenberg>
because a few months back i started documenting filters alphabetically from the start lol
<d1b2>
<johnsel> yes, I am stretched a little thin on time but it's something I might work on
<d1b2>
<johnsel> I'd like to get more familiar with them anyway
<d1b2>
<johnsel> but I want to do so many things so it's not my highest priority work, that's CI for now
<d1b2>
<johnsel> at least until we get those scripts running again
<azonenberg>
Yeah
<azonenberg>
we have a long list of devops TODOs
<d1b2>
<johnsel> we need more people
<azonenberg>
We do indeed
<d1b2>
<johnsel> but I guess once we get past launch we might find some more interested parties
<azonenberg>
Yeah. Basically it's a challenge growing a project at this stage
<azonenberg>
we can't get too many people too fast because i can't handhold 30 new devs at once
<azonenberg>
a lot of those devs will probably come from people who start out as users and want to contribute
<azonenberg>
but we dont have docs to help those users get started
<azonenberg>
but we dont have the staff to write those docs :D
<d1b2>
<johnsel> ah the age old chicken - dev - egg problem
<d1b2>
<aleksorsist> Soon I'll have a dozen units to lure you some new devs with 😄
<azonenberg>
:D
<d1b2>
<aleksorsist> Though I may not have the skillset to contribute I'm really looking forward to seeing what kind of work we can get done during the beta
<d1b2>
<aleksorsist> If anything, more users
<d1b2>
<azonenberg> Did you look at the website? any feedback especially on content?
<azonenberg>
(we already know the HTML docs are awful lol)
<d1b2>
<aleksorsist> I'd highly suggest embedding one of your videos using it
<d1b2>
<aleksorsist> The screenshot is awesome your videos give an instant sense of what you can really do with it
<azonenberg>
So i dont actually have much in the way of videos of ngscopeclient yet. the BERT one is actually the only one i released
<azonenberg>
i have a ton of glscopeclient but i obviously dont want to link to the old UI yet
<azonenberg>
anymore*
<d1b2>
<aleksorsist> Oh true
<azonenberg>
So i need to spend some time building some good demos using ngscopeclient
<azonenberg>
(as part of all this we also need to rename the github org)
<d1b2>
<aleksorsist> Perhaps a quick one with the sds2000x plus as that's what a lot of people will be working with?
<azonenberg>
So i'd rather do the demo using something higher end (i.e. faster). thunderscope, picoscope, lecroy, whatever
<azonenberg>
the siglents are sloooooow
<azonenberg>
and it doesnt really show off the software as well if you are getting 1-2 updates per second
<azonenberg>
I also dont have one to demo with :p
<d1b2>
<aleksorsist> Ah, well I also have to gather videos and screenshots of ThunderScope in action for the campaign so I can definitely provide those
<azonenberg>
I have a siglent load, power supply, and their rf signal generator. but none of their scopes
<azonenberg>
if you send me a beta unit, i can make some nice demo content with it
<azonenberg>
it's actually like the perfect demo device because it's fast but affordably priced
<d1b2>
<aleksorsist> Sweeeet, I'm getting CM quotes this week so the beta units should be rolling in by next month
<azonenberg>
and is really the only instrument that checks both right now. nothing priced <$10K can get even close to its waveform/sec update rate
<azonenberg>
except maybe the dslogic stuff which is not nearly as good
<d1b2>
<aleksorsist> Plus it'll be good for the CI rig
<d1b2>
<johnsel> yeah @aleksorsist let me know if there are things I can help with with my unit
<d1b2>
<aleksorsist> Have a play around and see what needs to be implemented
<d1b2>
<johnsel> I don't want to commit to being the scopehal person for thunderscope but know that I'm at your/other beta testers service in general
<azonenberg>
Yeah louis is working on supporting the driver as well
<azonenberg>
afaik
<d1b2>
<aleksorsist> Getting 50 ohm mode into the scopehal driver would be an easy win that opens up a lot more testing opportunities
<azonenberg>
yeah 50 ohm input capability will be nice. I'm gonna play with an AKL-PT5 once i get a dev unit
<d1b2>
<aleksorsist> Yup, he's on the beta list as well as they don't have a working unit at entropic atm
<azonenberg>
it's a 16 GHz probe so should be almost perfectly flat 10:1 within the operating band of the thunderscope lol
<d1b2>
<johnsel> yeah we should probably also discuss how we want to do a litex based driver at some point
<d1b2>
<johnsel> But I can work on 50ohm sure, that also eases up testing with what I have here
<d1b2>
<aleksorsist> That'll be a good test for 50 ohm mode, my measurements show 0.25dB flatness out to 500MHz
<d1b2>
<aleksorsist> Also yes, getting the litex gateware up to rev 4 is an important task
<d1b2>
<johnsel> does TS.Net currently talk to the litex driver?
<d1b2>
<johnsel> or can, rather
<d1b2>
<aleksorsist> No, just XDMA
<d1b2>
<johnsel> yeah so it's just the litex driver + python script + scopehal driver
<d1b2>
<johnsel> scopehal driver is using outdated APIs so needs work for sure
<azonenberg>
The AKL-PT5 is -20.47 to -20.90 dB measured from DC to 500 MHz
<azonenberg>
so about 0.43 dB flatness
<azonenberg>
so combined with a thunderscope should be <1 dB
<d1b2>
<johnsel> but I think a discussion about how an ideal driver would look and what it would talk to makes sense as well
<d1b2>
<johnsel> because I'm fairly certain it's not a random python script
<azonenberg>
yeah if we want to be able to sustain 8 Gbps streaming it's going to take some work especially if on less than monster hardware
<d1b2>
<aleksorsist> Definitely, I think it would be best to add it to TS.net, ideally as a compile option
<azonenberg>
i'm probably going to spend some time in vtune and nsight to optimize
<d1b2>
<aleksorsist> TS.net is a beastly triggering program, so the bottleneck is talking to scopehal
<d1b2>
<johnsel> I wonder about .net performance
<d1b2>
<johnsel> especially if we want to go even higher than 8gbps
<d1b2>
<aleksorsist> Talk to Mark on our server, he benchmarked it throughly
<d1b2>
<johnsel> at some point you will want a fat scopehal driver that is written in C++ I think
<d1b2>
<johnsel> if only because that opens up xdma like ability as well
<d1b2>
<aleksorsist> But I've never triggered at less than 8gbps, even on a 11th gen laptop i5
<d1b2>
<aleksorsist> Depends on where the triggers live
<d1b2>
<aleksorsist> Since as of now scopehal feeds on triggered data
<d1b2>
<johnsel> Sure, it's 1Gbyte/s you can still copy that a few times around reasonably well
<azonenberg>
One of the optimizations i want to work on is doing raw integer to float32 conversion on the GPU
<d1b2>
<aleksorsist> If we want a trigger block and accept raw data then that's a good path
<azonenberg>
i need to test, but i think it will be faster than doing it in AVX then moving the 4x expanded data out over pcie
<azonenberg>
and yes a vulkan based trigger is probably going to be where we want to end up long term
<d1b2>
<aleksorsist> That would fit in very well with the filter graph view
<d1b2>
<aleksorsist> But for now I think the bridge is the way to go for dev
<d1b2>
<aleksorsist> which IIRC was the concensus in the dev meeting
<azonenberg>
Yeah. like i said i'll spend some time in vtune and nsight optimizing on the scopehal side once i get my hands on a dev unit
<azonenberg>
thunderscope is literally the fastest scope we've ever hooked to scopehal by a factor of 3-4x, in terms of how much raw data it pushes
<azonenberg>
it's finding bottlenecks we didn't know we had
<d1b2>
<aleksorsist> Oh I can't wait to hand you 4GB/s 🙂
<d1b2>
<aleksorsist> But for now yes, 1GB/s is a challange
<azonenberg>
4GB/s? you gonna make a 4 channel scope with a hmcad per channel?
<azonenberg>
because that was on my roadmap as well
<d1b2>
<johnsel> For TS itself it will suffice, but we already know we want to do multiples of that so it may be worth thinking about it since we need to write code for LiteX anyway
<azonenberg>
4x 1 Gsps would be a decent scope
<d1b2>
<aleksorsist> Nah, one of those TI parts that can sample at 1GSPS on every channel
<d1b2>
<aleksorsist> No interleaving though
<d1b2>
<aleksorsist> I'm leaving that for @johnsel's 5gsps beast
<d1b2>
<johnsel> 10
<d1b2>
<johnsel> I just can't get more than 5 out of it right now over pcie
<d1b2>
<johnsel> not enough lanes at PCIe2.0
<d1b2>
<aleksorsist> PCIe gen 4 commeth
<d1b2>
<johnsel> Well, these chips are so cheap
<azonenberg>
So my next instrumentation project i think is going to be a BERT
<d1b2>
<johnsel> I think you can max out everything and just about reach 10gbps
<azonenberg>
both because somebody were mean to me about support, and because i want an "easy" ultrascale+ FPGA project before i do something with more oomph
<azonenberg>
but after that, an AD9213 scope is on my radar
<azonenberg>
i already have a 6 Gsps AD9213 somebody bought me and i kinda feel bad i've been too busy to make a board for it after how much they spent on it
<d1b2>
<johnsel> Yes it'd be nice to go to a newer chip, they are not too much more expensive in bulk, but I have a partial kintex7 design right now I can use
<azonenberg>
My vision was an au25p (for the 6G speed grade) or ku/ku+ (for the 10G) plus 1-2 channels of DDR4, per ADC
<d1b2>
<johnsel> Anyway they can be parallel efforts to add support in TS.net for LiteX
<azonenberg>
then a root fpga running the PC interface and triggering
<d1b2>
<johnsel> but I do want a fatter LiteX driver in scopehal
<azonenberg>
Yeah i'm all for that. I also want a litescope driver
<d1b2>
<johnsel> I want to play with XDMA to the nvidia card directly
<d1b2>
<johnsel> This is only relevant for PCIe though it's not possible to do to this over Thunderbolt
<d1b2>
<johnsel> which is sad
<d1b2>
<johnsel> but still I want to learn about it
<d1b2>
<aleksorsist> I'll be using one AU10P/AU15P with one SODIMM of DDR4 so you may be able to build off of that easily
<d1b2>
<johnsel> there's also some interesting follow up ideas to implement GPU based decompression, and fpga based compression
<d1b2>
<aleksorsist> Until TB5 gets mainstream adoption, this will be the only way to hit 10GSPS anyway
<d1b2>
<johnsel> ofcourse, but that is also why I was looking at data compression
<d1b2>
<johnsel> so far it doesn't look too great
<d1b2>
<johnsel> I just steal every idea they implement in game technology
<d1b2>
<johnsel> and try to fit it to a scope
<d1b2>
<johnsel> because why not
<azonenberg>
lol
<azonenberg>
i swear if i find a pull request for fully destructible environments with dynamic lighting in ngscopeclient in a few months...
<azonenberg>
we don't need weather effects either
* azonenberg
carefully places oscilloscope on top of a giant red oil drum labeled "explosive"
<d1b2>
<johnsel> oh come on, like our discussions have produced such bad outcomes
<azonenberg>
lol
<d1b2>
<johnsel> the only reason I was able to convince you to use that is because I hooked imgui into a game to pull its frame data to build an AI for Dark Souls 3
<d1b2>
<johnsel> I should put that thing online sometime
<d1b2>
<johnsel> but yeah that and some other unrelated UE5 stuff is why I knew we'd need to drop gtk
<d1b2>
<johnsel> I like performance analyzing game engines, they have a tendency to push through enourmous amounts of data
<azonenberg>
I mean i had done my own profiling on GTK for a while too
<azonenberg>
there were a couple big factors convincing me to move
<azonenberg>
one was seeing how much time each frame was spent in GTK overehad
<d1b2>
<johnsel> scraps physics engine for ngscopeclient from to-do list
<azonenberg>
creating and switching opengl contexts for each viewport etc
<azonenberg>
another was realizing how much of a pain in the butt opencl and GL 4.3 was wrt platform support especially macos
<azonenberg>
vulkan seems the obvious way forward
<azonenberg>
and gtk didnt really work with it anyway
<d1b2>
<johnsel> sure sure, I'm just saying our discussions were based in my knowledge from game engines on my end
<d1b2>
<johnsel> and ultimately helped convince you
<d1b2>
<johnsel> but I wasn't the first to bring up imgui though haha
<azonenberg>
yeah bvernoux had been pushing it for a while and at the time i didnt want to move to a new gui tookit due to overhead
<azonenberg>
but in retrospect it was absolutely the right call
<azonenberg>
it was like 2-3 weeks ago that ngscopeclient surpassed glscopeclient in lines of code
<azonenberg>
but it was vastly better in feature set
<azonenberg>
i.e. we got more done in less code
<azonenberg>
all of the properties dialogs etc just fit the imgui paradigm so much better
<d1b2>
<johnsel> yeah it's a pretty amazing thing
<d1b2>
<johnsel> it's used by pretty much every game hack imaginable as well
<d1b2>
<johnsel> which reminds me naming my character "NOTONLINENOTAHACKJUSTAI" because I kept getting banned for online play when I accidently pressed it in DS3
<d1b2>
<johnsel> hansemro: I see you are making changes to the latex. It would be good to discuss if you are planning to do more work on it, I don't know if you've read the discussion above but we are considering changing the way the html/pdf are generated, potentially from a markdown as primary source. I'd like to spend some time on it soon to see if we can improve a latex -> html workflow, or if we need to convert to markdown first (which I do expect). In
<d1b2>
the latter case (and likely also in the first places) we could be undoing each other's work
<d1b2>
<johnsel> There's also the option "it's too much work we're keeping things as is" ofcourse. Either way I don't want to step on each others toes so to say
<juh>
I haven't exactly read the entire docs, is there anything that springs to mind as "not very markdown-able"?
<d1b2>
<johnsel> I don't think so, but it's structured to structured conversion so you never know what you get from these tools
<azonenberg>
@johnsel the immediate changes he's making are focusing on making it compile at all under CI
<azonenberg>
which is a critical blocker
<azonenberg>
once that's fixed, we can work on the reformatting at a more leisurely pace
<azonenberg>
but yes you two should coordinate
<d1b2>
<johnsel> well the last commit is a style change commit
<d1b2>
<johnsel> so what I would not want is for hansemro to work on prettying up the html output a lot only for me to come with some way that undoes all that work again
<d1b2>
<johnsel> @hansemro are you the same hasemro?
<d1b2>
<hansemro> @johnsel, yes, that is me. The PR boils down to replacing \thickhline and \thinhline with \toprule and \midrule, then replacing inconsistent use of thick and thin lines in tables (an issue present in PDF). We could very well drop the style commits if we plan on something else entirely.
<d1b2>
<hansemro> I did not want to introduce custom CSS styles for tables, hence I went with this route
<d1b2>
<hansemro> For reference, replacing \thickhline and \thinhline fixes builds on debian/ubuntu/CI
<d1b2>
<johnsel> Definitely no need to remove it, my only point is that if we want to look into a different method of generating the outputs it's debatable how much time should be spent on prettifying especially the html
<d1b2>
<johnsel> so that's just what I wanted to make sure to discuss
<d1b2>
<hansemro> Okay, I see you are exploring the possibility of generating docs from markdown and maybe exploring more modern options. Yes, this is a direction I think is more sensible and sustainable.
<d1b2>
<hansemro> I think we can have the PR merged just to make CI happy, then focus our efforts on rewriting the docs in markdown.
<azonenberg>
Sounds like you have a plan then. I'll review and merge the PR tonight and let you two figure out the path forward on the docs then?
<azonenberg>
also @hansemro let me know what the status of your siglent PRs is and what if anything is ready
<azonenberg>
Oh and the other thing to look into is uploading doxygen from the source as developer documentation
<azonenberg>
i would love to build that out more and have proper dev docs
<azonenberg>
we have doxygen comments now but far from 100% doc coverage of major APIs etc
<d1b2>
<johnsel> in theory that should also be possible to host on readthedocs and generate a similar way