Remix.run Logo
▲ ssl-3 a day ago

That's really neat.

But now, I really want to know why my office suite needs to tell my printer what day of the week it is.

If the printer is smart enough to make use of that kind of information, then isn't it also smart enough to sort that out on its own? If so, then it seems superfluous.

▲arcfour a day ago | parent | next [-]

Doesn't seem to me like it is telling the printer what day of the week it is because the printer needs to know so much as it is generating a PostScript file for the printer to use and is adding the creation date as either a convention or requirement of the format, and not the printer.

▲gpvos a day ago | parent | next [-]

Not a requirement, but indeed more of a convention or at least a possibility. Postscript files can be postprocessed or read by humans, and then this kind of metadata can be useful.

▲ssl-3 a day ago | parent | prev | next [-]

Other things were reported to successfully be printed on Tuesdays, so that inclusion (or at least, this form of it) is empirically unnecessary.

And the whole CreationDate field is optional in PostScript[1], anyway.

[1]: https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf

▲notatoad a day ago | parent [-]

>so that inclusion empirically unnecessary

this seems like a post-rationalization. when an app generates a file to send to another service, it's usually a good practice to timestamp that. unless you're severely bandwidth-constrained, putting a timestamp in your protocol almost always solves more problems than it creates. "we shouldn't include a timestamp because it might at some point trigger a date-math bug" is just not how software gets built.

▲adrianN a day ago | parent [-]

Maybe we should think about building software in a way that only adds stuff that is truly necessary.

▲swsieber a day ago | parent | next [-]

I have. I don't like it. I'd rather have the ability to debug, redundant checks, etc. than only what's truly necessary.

▲notatoad a day ago | parent | prev [-]

if this bug was caused by a lack of a datestamp instead of the inclusion of one, you'd be here leaving comments about how silly it was they didn't include something as standard and widely useful as a datestamp, and that of course that was necessary.

▲M95D 5 hours ago | parent [-]

A datestamp is a privacy risk. If it's optional, don't include it. If it's not optional, it's a spec bug! It should be optional. Or even better, removed entirely.

▲bombcar a day ago | parent | prev [-]

Exactly, it was using the file utility to determine what it was so it could print it correctly (by processing it if needed to a format the printer understood) and there was a bug in that.

▲bitwize a day ago | parent [-]

This is one of those "VLC is slow to start because of a bug in Windows" things. It's VLC's responsibility to ensure their program runs properly on the OS people actually have. It's LibreOffice's responsibility to ensure that their files print on Tuesday irrespective of bugs in CUPS (which ships with the Mac).

▲ssl-3 a day ago | parent | next [-]

It's important that software behaves well on systems with bugs. (All systems have bugs.)

▲braiamp a day ago | parent | prev [-]

So, Windows gets a pass for being sloppy coded? Give me a break. Every software must fulfill their contract with every consumer rather than consumer have to work around producers quirks. "All means are fair except solving the problem"[0]

0: https://yosefk.com/blog/all-means-are-fair-except-solving-th...

▲olalonde a day ago | parent | prev [-]

Can be useful to distinguish when a print job was submitted from when it was actually received by the printer. That distinction matters when printers go offline and jobs get queued.

▲ssl-3 a day ago | parent [-]

Is it possible or practical to examine a printer's internal queue for jobs that might include this (completely optional) CreationDate field?

If not, then: I'm not sure that the distinction means anything. :)

▲olalonde a day ago | parent [-]

Yes. Many printers have a web interface where you can see active jobs, job history, timestamps, and document information. Some even have a physical control panel that lets you inspect this information directly from a touchscreen.

▲ssl-3 a day ago | parent [-]

Right. But none of that comes from the CreationDate field of a postscript job.

▲olalonde 19 hours ago | parent | next [-]

Seems you learned a lot about printers since asking your question.

By the way, it's mentioned in a number of printer manuals, so it's definitely used, e.g.: https://www.scribd.com/document/899003124/Magicolor-2200-use...

▲ssl-3 4 hours ago | parent [-]

Which part of that manual relates to a CreationDate field within a postscript print job?

I'm not seeing it.

▲arcfour 20 hours ago | parent | prev [-]

Are you sure? I would be more surprised if it did not come from there, if the field was present at all. You're already processing the PostScript... Might as well use the metadata.

▲ssl-3 19 hours ago | parent [-]

I'm sure that every print queue I've ever used didn't appear to care a lick about the content beyond acceptance. It's a buffer, not a processor.