Easy method to generate latest Doc from md to pdf?

Hi guys, I regularly teach Beginning Lightburn at a maker group. Traditionally I have taken the documentation pdf and edited it into a reasonable printable format (page numbers section breaks, etc.). Lately it has gotten quite stale. I know that you keep the .md files up to date. Is there some tooling I could use to create the PDF or a printable format? I build workbooks for my classes.

We have not made any changes to the online documentation in a number of months:
https://github.com/LightBurnSoftware/Documentation

You can see the commit log here to know exactly what changes were made and when:

Our team has been hard at work writing new documentation, which is still under construction, but you can see it here:

https://lightburnsoftware.github.io/NewDocs/index.html

@adammhaile - does the PDF version in NewDocs get rebuilt every single time you make an update?

It does, yes.

Thank you for the feedback, Adam impersonator :slight_smile:

So Bill, there you go - NewDocs’ PDF will be up to date for you always.

I have a python script that builds a single .md file from all the individual files, and then launches Typora (a markdown editor) to do the PDF export.

It’s available in the old documentation repo as “CompileDocs.py”.

1 Like

@raykholo, where does NewDocs drop the PDF? Is is accessible from a URL?

Please to read the page I linked :slight_smile:

I am obviously blind today :crazy_face: I just finished walking the whole document front to back to estimate different ways to to approach it. Thanks for the pointer. Are sources for the doc “behind the curtain” at this point?

The raw markdown files for NewDocs are in a closed GitHub repo, yes.

Thanks for your help. Post-processing this PDF will be much easier than the old one. (The doc is better too… especially for beginners.)

Maker groups create a special breed of user. They aren’t allowed to mess with the machine settings and are required to sign-in/sign-out to allow us to reset all of the Lightburn parameters as part of the login process. I’ve caught people with the console open trying to figure out what to type. Yow! We have one 100W laser (BOSS 1630) shared among ~150 potential users. Their skills run from “incredible” to “OMG I can’t watch.” Training and documentation are our biggest defense to someone screwing up the machine.

1 Like

Don’t worry, I don’t read more than the rest of people, and anyone who knows me would know that’s saying something.

And Boss would use a DSP controller, so “what console?”

We’re friends with a number of people that are MakerSpace directors and big in that part of the world, so we’ve heard quite a bit about the inner workings of such things…

At some point someone had the console window open. I think it was quite a few releases back. If memory serves me right they had created some new devices and were trying to make things connect. (All bad behavior in a shared space). I do 3D Printing and CNC milling as hobbies and in general consoles are dangerous in the hands of an unknowledgeable user.

Yeah we have had a few good stories come out of our shop as it is only used by 55+ users. Like the guy who wanted to etch a garden stone (to which we replied “sure” not realizing the thing was 50lbs+. :face_with_raised_eyebrow: ) The monitor heard this “BWWANG” as he dropped it onto the laser table thereby knocking the right side down by 20mm. doh!

You might be interested in some of the other stuff we have under the hood - LightBurn can forcibly reset most settings to specific defaults every time you run it, if you want it to, and you get to pick and choose which settings are reset.

Especially useful if it’s a shared login, but even if it isn’t, it can be helpful to keep users within certain constraints if they aren’t savvy.

And yes, one of the bigger motivations for the new docs is a stronger focus on things for new users. If you start from the beginner walkthrough page and just keep clicking Next Page from there until you can’t, you cover most of the stuff that trips up new users, and we’re filling in the rest of the content slowly. It’s much cleaner and easier to navigate and search too.

I absolutely agree with the new docs being better. Thanks for the investment in the new docs. I used them for a zoom class last night.

I would be interested in the “under the hood” resets. I did it with a quick python script that terminates Lightburn if running, shoves a default configuration into place and starts Lightburn. Obviously not the greatest method, but we have huge challenges with people leaving LB in imperial mode, burn only selected checked, and all sorts of settings that leave the next guy scratching his head why he can’t get it work.

If there’s a second file in the prefs folder called “defaultprefs.ini”, it’ll read that one after reading the main prefs. Anything in the “defaultprefs.ini” file will override the main prefs. It will then load a file called “defaultprefs.ini” from the LightBurn application folder (which is system wide) and those will override the other two.

The prefs are just JSON, so they’re not too hard to edit. Make a copy of “prefs.ini” and rename it to “defaultprefs.ini” and delete anything that you don’t want to be overridden. Whatever is left will be the “enforced state” when you re-run LightBurn.

I’ve attached an example as a .txt file just to show you what it looks like. The last line is “units” (0 is mm/sec) and the second last line, “WindowState” actually stores the layout of all the main window contents, so you could even force that if you want to. Someone would have to go through and figure out which bits you want to enforce, but this method means I don’t have to write a ton of UI switches to manage it, and it’ll scale to include any new settings we add in the future.

Things like cut settings in the layers should probably be removed, and this hasn’t been tested to make sure it works with absolutely every pref in the device settings, and it won’t enforce anything in the machine settings, but it’s being used by a few places already with good feedback.

defaultprefs.txt (3.2 KB)

That is excellent! Thanks so much. I will drop that into place (probably tomorrow). We have to enforce machine settings and likely window layout as well. I’ll experiment on it this evening. In the beginning I was going to write a UI-based tool for the monitors and they only know a skosh more than the users. In the end, we chose what to harden and so the brute force method was done. This is a much cleaner setup.

Users can change their settings still, but they won’t stick, and a savvy user could potentially edit the file, but if you have user access control and they aren’t allowed to write to C:\program files, that would work. Even the window layout prefs are stored here, so that gets you that for free too.

Yep. I got that. The primary challenge is a person who walks in, loads his file from a USB, changes a bunch of settings (including closing/opening windows), burns his design and walks away. The next person is a total noob and nothing matches what they have learned. Myself or another person gets a call “Lightburn is broken.” Those calls are not as bad as some “well-meaning” person who goes in and starts changing everything trying to make it work. This mechanism will allow us to tell users “If something doesn’t work right for you, restart Lightburn.” It should solve a number of issues for new laser users(other than speed/power LOL)

For those, the material library is a good one, but yes, I get where you’re going here. The bulk case is what this solves.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.