Computing desk
< May 11	<< Apr \| May \| Jun >>	May 13 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

May 12[edit]

DOCX file bloated by a mysterious PNG[edit]

I've just today received a DOCX file with a small amount of text and (as I view it in LibreOffice Writer) minimal formatting and no graphics. I'd expect it to be well under 30 kB and very likely half of that. However, it's 483 kB. A DOCX file is of course a kind of ZIP file. Inside this DOCX file was pretty much what I'd expect, but with the addition of word/media/image1.png, 478 kB of a 635×635 px speckled blue square. What's up with this? (Some lame attempt at malware, perhaps?) More.coffy (talk) 11:42, 12 May 2020 (UTC)[reply]

Without seeing the file, there's no way to be sure, but it's unlikely to hold malware. Is it possible that this image is supposed to be tiled to form the background of a web-page/email/document? The fact it's a fairly small perfect square brought back memories of constructing background wallpapers for my Windows 3.1 computer back in the day. Matt Deres (talk) 19:34, 12 May 2020 (UTC)[reply]

Thank you, Matt Deres. I'm sure that the image wasn't supposed to be tiled for a background. (The context would have prescribed sober black text on a sober white background.) And putting aside the inappropriateness of a tiled blue background, such a background could have been achieved with a tile much smaller than 635×635 px (64×64 px would have been adequate). Also, 478 kB is a lot bigger than what I'd expect for an image that looks like this. As for bringing back memories, yes, I have a feeling that a few years ago I was sometimes encountering oddly large DOCX files that contained seemingly pointless graphics files. But I think I'll just file this matter away under "Things I'd investigate further if only there were 30 hours in each day". More.coffy (talk) 21:53, 12 May 2020 (UTC)[reply]

How many different colours are there? If it is a small number, particularly if a power of two, this may be an amateur attempt at 8-bit BPCS-steganography. --Lambiam 10:59, 13 May 2020 (UTC)[reply]

To my untrained eye, viewing this at 400% shows perhaps four different shades of blue. GIMP's "image properties" says color space is RGB color, precision is 8-bit gamma integer, size in memory is 4.2MB; does any of these suggest anything of interest? More.coffy (talk) 13:34, 13 May 2020 (UTC)[reply]

Assuming the file was created in Microsoft Word, a safe assumption, my default guess is some Word bug or misfeature. When you hear hoofbeats, think horses, not zebras. Word is a giant pile of hacks held together with duct tape and I'm pretty sure no single human understands the whole codebase. It's not like the average Word user pays any attention to the size of a file it creates. --47.146.63.87 (talk) 20:50, 13 May 2020 (UTC)[reply]

Ha! Well said. More.coffy (talk) 21:56, 13 May 2020 (UTC)[reply]

Best upload it to OPSWAT's multi-scanner just to make sure. Zebras and hoofbeats aside, if all good reasons for that picture's existence have been eliminated, what remains are evil reasons. 93.136.73.59 (talk) 00:33, 14 May 2020 (UTC)[reply]

https://metadefender.opswat.com/?lang=en doesn't suggest that it's suspicious in any way. Well, that's reassuring. Thanks for the link! More.coffy (talk) 05:34, 14 May 2020 (UTC)[reply]

Laptop keyboard keycap[edit]

If I keep wiping down my laptop keycaps (Dell Insprion) with a damp tissue, will it cause long term wear and tear? --Thegooduser Life Begins With a Smile :) 🍁 16:03, 12 May 2020 (UTC)[reply]

Thegooduser, probably no more than if you put your fingers on them to type.

Make sure that your laptop is powered off (not merely asleep) when you wipe it down, and allow it to dry thoroughly before powering on. Elizium23 (talk) 16:22, 12 May 2020 (UTC)[reply]

Elizium23 Does dell sell individual keycaps? The backspace and ctrl key seem loose for some reason --Thegooduser Life Begins With a Smile :) 🍁 16:26, 12 May 2020 (UTC)[reply]

I don't know. Search here but my generic searches have not turned up much in the way of individual keycaps. Your other option would be to find someone on eBay parting one out, and purchase the whole keyboard. Elizium23 (talk) 16:31, 12 May 2020 (UTC)[reply]

So, considering this is the reference desk - have any of our previous respondents actually looked for a reference? Come on, folks - we have standards here, and we need to uphold them... it simply is not good enough to rely on "common-knowledge" especially when you are actually incorrect.

Here is the official guidance from Dell: Guidance for Keeping Your Dell Technologies Equipment Clean - there are specific instructions for cleaning to avoid acute or long-term damage to your product.

Wiping down some electronics - especially a lot of commercially-available keyboards - can easily cause permanent cosmetic or functional damage. Follow the guidelines from your manufacturer with respect to the type of cleaner, and pay careful attention to cleaning-chemical compatibility. Many household chemical cleaners - and sometimes, even plain old water - can cause cosmetic damage to the kinds of paints and dyes that are used on commercially-available computer keyboards.

Nimur (talk) 17:12, 12 May 2020 (UTC)[reply]

Nimur, other than missing the part about 70% alcohol with 30% water, everything I said conforms to what is recommended in the reference you provided. Quit attacking me. Elizium23 (talk) 17:21, 12 May 2020 (UTC)[reply]

My statements were not personally directed at you or any other specific contributors in particular. I am simply reminding all of our contributors that this website is a place to provide encyclopedic reference material in the hopes of building a better encyclopedia; this isn't a general discussion-forum on the topic of computer-support. Nimur (talk) 18:37, 12 May 2020 (UTC)[reply]

Typing weird characters[edit]

With the advent of Unicode, the standard character set of both Linux and Windows now includes 65536 different characters, which are legal characters in file names too. This is all well and good, but what if I have to type a file name consisting of weird characters on a Linux terminal? The Cyrillic characters alone are impossible to type on my keyboard. So far I have resorted to using the Unix * wild card character, but it won't work if the name part of the file name does not contain enough typeable characters to distinguish it. JIP | Talk 22:56, 12 May 2020 (UTC)[reply]

JIP, what kind of Linux terminal? All graphical desktop environments have language and input method settings whereby you can remap your keyboard to that of another country's or another language. And they also have the Compose Char key which can assist in typing accented glyphs and similar characters.

The method of setting up multilingual support is dependent on your distribution and its desktop environment. Consult your documentation for best results. Elizium23 (talk) 23:45, 12 May 2020 (UTC)[reply]

Point of detail: Unicode grew beyond 65,536 characters long ago. The original hope was that any Unicode character could always fit in 16 bits, but that hasn't been true since Unicode 2.0, it says here. (The current version is 13.0.) --76.71.5.208 (talk) 01:56, 13 May 2020 (UTC)[reply]

To be more specific, Unicode has 65,536 code points in the Basic Multilingual Plane, which contain the most common characters in the most common languages that are small enough to fit. There is a hard limit of 17 such planes in UTF-16. UTF-8 handles 32 planes.

So far Unicode uses the following planes:

* Plane 0: Basic Multilingual Plane (common characters)

* Plane 1: Supplementary Multilingual Plane (hieroglyphics, musical notation, math symbols, playing cards, dominos, and of course the ever-popular Emojis 💩.

* Plane 2: Chinese, Japanese, and Korean characters (there are a lot of them!).

* Plane 3: Even more Chinese, Japanese, and Korean characters.

* Plane 14: Flags, alternate glyphs for some characters.

* Planes 15-16: Private Use Areas (some of which are used on Wikipedia; see MOS:PUA.)

--Guy Macon (talk) 02:49, 13 May 2020 (UTC)[reply]

Unicode input describes how to enter characters numerically. For a few people, whose day-to-day work involves lots of work in multiple incompatible key mappings (e.g. translators), it's possible to have say a Latin and Cyrillic keyboard plugged in simultaneously. On Linux, setting the respective mappings of the keyboard devices would be done with setxkbmap. -- Finlay McWalter··–·Talk 13:55, 13 May 2020 (UTC)[reply]

Finlay McWalter, it may be setxkbmap under the hood, but most mere mortals click an "En" icon or press a key combination to change the keyboard layout. As I have said, this is dependent on your desktop environment and it's best to learn how to do it the right way, so that the installed layouts are consistent with your preferences. Elizium23 (talk) 14:01, 13 May 2020 (UTC)[reply]

Fun fact: literally anything other than null is legal in Unix filenames, and this has always been the case. Unicode doesn't affect anything here at the filesystem level. Yes, this means newlines, tab stops, and whatever else is all legal. From the kernel perspective, a file is an inode, and a filename is just a null-terminated chunk of bytes associated with a directory inode. When a process opens a file by name, it passes a pathname to the kernel via a syscall such as open(2), the kernel searches the filesystem for it, and if successful the kernel returns a file descriptor (fd). Further interaction with the file is done using the fd. Whatever a filename "shows up as" is up to whatever the process does with the filename. If something like find prints out the filename in a terminal emulator, find spits it out on its stdout, the emulator reads it, and it tries to interpret it according to the current locale and display it using whatever character set the emulator is using. You can observe all the gory details yourself with something like strace. --47.146.63.87 (talk) 21:44, 13 May 2020 (UTC)[reply]

And to follow up on this, practical advice for helping with your problem: a lot of the time you can just avoid typing file names, which is useful for saving time even when they're just boring old ASCII. find (especially GNU find, which you're probably using) is incredibly powerful and useful for doing things to files; you will find it well worth your time to gain some expertise in using it. find's -exec can execute any arbitrary command on the files matching a particular query. GNU find and some other GNU tools let you both view and refer to files by inode number, so even if you can't easily isolate particular files in an automated way, you can just look at their inode numbers and use those instead of file names. Most modern GUI environments have mostly-Unicode-compatible copy-and-paste, and most common terminal emulators support copy-and-paste, so that's another useful option for small numbers of files. And there are various programs that let you do file operations using a GUI-driven environment: Midnight Commander is one popular option. Finally, if you need even more complex stuff like parsing file contents, there are plenty of libraries available for popular programming languages that can often greatly simplify things for you. Keep in mind that if it seems like something is a common problem people have, you're probably right, and there's a good chance others have written stuff to make doing it easier. --47.146.63.87 (talk) 19:05, 14 May 2020 (UTC)[reply]

Literally anything other than null? If the file name contains a forward slash (/), then isn't it impossible to access the file by name, because the file system thinks the slash is a directory separator? JIP | Talk 18:33, 15 May 2020 (UTC)[reply]

Yeah, you caught me in a technicality there. ;) Correct, file names can't contain / either. Path names can, of course, since that's the directory separator. --47.146.63.87 (talk) 06:13, 16 May 2020 (UTC)[reply]