this post was submitted on 26 Feb 2024
189 points (95.7% liked)
Programming
17314 readers
508 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm starting to understand why printers are so horrible
Just what was in the main repo (at least one other repo was used for the more secure parts of the code) was a little over 4 million lines. But yeah there's a lot of complexity behind printers that I didn't think about until I had worked on them. Of course that doesn't mean they have to be terrible, it's just easier to fall into without a good plan (spoiler alert: the specific firmware I was working in didn't have a good plan)
Out of curiosity do you have any good examples of this hidden complexity? I've always kinda wondered how printers work behind the scenes.
A lot of the complexity came from around various scenarios you could be in; my goto whenever people would ask me "Why can't someone just make printer firmware simple?" is that you could, if you only wanted to copy in one size with one paper type, no margin changes, and never do anything else.
There's just so many different control paths that need to act differently; many of the bugs I worked on involved scaling and margins. Trying to make sure the image ended up in a proper form before it made it to hardware (which as more complexity, ran on a different processor and OS than the backend so that it could run realtime) when dealing with different input types (flatbed scanner vs a document feeder, which could be a everyday size, or like 3 feet long) different paper sizes, scaling, and output paper. I mainly worked on the copy pipeline, but that also was very complex, involving up to, something like, 7 different pieces in the pipe to transform the image.
Each piece in the pipeline was decently complex, with a few having their own team dedicated to them. In theory, any piece that wasn't an image provider or consumer could go in any order — although in practice that didn't happen — so it had to be designed around different types of image containers that could come in.
All of that was also working alongside the job framework, which communicated with the hardware, and made sure what state jobs were in, when different pieces of the pipeline could be available to different jobs, locking out jobs when someone is using the UI in certain states so that they don't think what's printing is their job, and handling jobs through any of other interface (like network or web.)
That's the big stuff that I touched; but there was also localization; the UI and web interfaces as a whole; the more OS side of the printer like logging in, networking, or configuration; and internal pages — any page that the printer generates itself, like a report or test page. I'm sure there's a lot more than that, and this is just what I'm aware of.
Wow, thank you