[deleted]
“My wife has complained that OpenOffice will never print on Tuesdays” (2009)
71–80 of 216 posts
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#72Earlier quoted context omitted.
Excel mis-identifies CSV files whose first column is named "ID" as SYLK files. But who would EVER think of naming the first column of a spreadsheet "ID"? https://www.optibrium.com/community/forums/6-general-how-do-... >Q: I have saved the result table from admensa into .csv format. However I am not able to open in excel. It is said that SYLK: file format is not valid. Do you have any experience on it? Thanks. >A: Thi…
Excel actually mostly ignores the extension and relies on heuristics to detect the file type on load. Many web applications used to implement "XLS export" by writing out CSV file with .xls extension. This magic detection of file type has one unfortunate side effect: it is not exactly obvious how to convince Excel to load plain text data that is not CSV with delimiters from the current locale. (which is major PITA wit…
You’ll have to excuse me because I’m not in front of a windows computer right now, but if you open excel first, there is a data tab on the ribbon and an import data wizard or something like that and you can tell it what the delimiter is. You can also apply types to columns and whatnot before importing. Not the quickest but does help extract the data.
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#73This is why one of my favorite features in the original MacOS filesystem was type/creator fields (four uppercase letters each). Yes, it was possible for developers to create collisions, but it was still better than the UNIX method of applying fragile heuristics to the file contents. IMO it would still be a good idea to replicate this (minus the four-character limitation) with a standardized extended attribute, fallin…
The separation between type and creator had other beneficial side effects. The Type code told you which apps _could_ open a file (by drag and drop or via the file chooser dialog). The creator code told you which app _would_ be chosen when the file was opened in the Finder (e.g., double-clicked). So HTML documents I had created in some web authoring tool would open in it for editing, whereas those I had saved from a w…
ResEdit was the apple program that could change it. Unfortunately, I don't remember off the top of my head if it shipped with the system or only with some of the developer tools. I _think_ early versions had it.
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#74There is a GitHub repository that collects such debugging stories (this one included) [1].
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#75Some years back I had a case where a co-worker complained his mouse didn't work in the afternoon. Eventually I went to have a look, and he demo'ed the issue; sure enough the mouse was completely unresponsive. Luckily I guessed the issue immediately and quicky demonstrated - with a shrug - that the mouse "works fine for me". Thing was I'd spotted there was strong sunlight through the window hitting the mouse; guessing…
This reminds me of a similar issue I've experienced. A colleague always put his jacket onto his chair. Almost every time he took it off, his monitor connection broke for a few seconds. This mystery was never fully solved, but our best guess was some static (from the jacket-chair-friction) causing issues with his VGA-HDMI adapter.
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#76I got some legacy applications of work. One of them needed a new feature for something. Including database update scripts. So it was changed, very carefull because it had to use a database trigger ( ms sql) which i haven't used before.
It was released in demo/test environment, for 1-2 months and there was never an error.
When it got deployed into production, the integrating applications with it went to shit. Rollbacked everything and it was fine again. Made me seriously doubt myselve. I contacted the older devs that touched parts of the database and application, they didn't saw any issues.
Fast forward 2 months, i heard it was deployed again into production without any issues.
1 month afterwards, a colleague found an "issue" with the deployments. In short: if you deploy to production, for some applications it would deploy and older version ( 50% chance since a swap happened).
Urgh
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#77Earlier quoted context omitted.
Excel actually mostly ignores the extension and relies on heuristics to detect the file type on load. Many web applications used to implement "XLS export" by writing out CSV file with .xls extension. This magic detection of file type has one unfortunate side effect: it is not exactly obvious how to convince Excel to load plain text data that is not CSV with delimiters from the current locale. (which is major PITA wit…
You’ll have to excuse me because I’m not in front of a windows computer right now, but if you open excel first, there is a data tab on the ribbon and an import data wizard or something like that and you can tell it what the delimiter is. You can also apply types to columns and whatnot before importing. Not the quickest but does help extract the data.
This is a fairly new feature in Excel.
The lack of this feature pushed a lot of scientists to OpenOffice/LibreOffice Calc. At first, just to open the file and "Save as Excel", but of course, then they start using Calc.
(At least that's my experience writing scientific software in Europe. Excel localized not just display, but the input and output. With Calc you could just open a file as "pipe separated UTF-8" and be done with it.)
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#78This is why one of my favorite features in the original MacOS filesystem was type/creator fields (four uppercase letters each). Yes, it was possible for developers to create collisions, but it was still better than the UNIX method of applying fragile heuristics to the file contents. IMO it would still be a good idea to replicate this (minus the four-character limitation) with a standardized extended attribute, fallin…
My favorite part was that MacOS's user account permissions used those creator codes to decide whether you were allowed to run an application or not.
Want to run the Unreal Tournament demo in the school computer lab? ResEdit its creator code to something you were allowed to run, and it'd fire right up.
"RASM" was a favorite, belonging to the remote access status monitor utility. All users automatically had access to run it, and it didn't have any document relationships that were going to be confused by applying it to other applications.
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#79Earlier quoted context omitted.
I think the issue here is the question that should be being asked is: "is this a postscript file?". `file` answers a different question, "what is the most likely type for this file?"
There is no perfect heuristic here, because what if you, for example, want to print a plain text file that happens to be PostScript?
In most cases, you can't print plaintext easily to a printer, it needs some format like PS, so your PS file would be converted into a PS script that outputs your PS file.
Re: “My wife has complained that OpenOffice will never print on Tuesdays” (2009)
#80This is why one of my favorite features in the original MacOS filesystem was type/creator fields (four uppercase letters each). Yes, it was possible for developers to create collisions, but it was still better than the UNIX method of applying fragile heuristics to the file contents. IMO it would still be a good idea to replicate this (minus the four-character limitation) with a standardized extended attribute, fallin…
Type/creator codes were any 4-byte OSType, actually. ASCII values were commonly used, for obvious reasons, but not required.
I stand corrected. Thank you.