Computing desk
< December 26	<< Nov \| December \| Jan >>	December 28 >

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

December 27

Activating IPA Extensions for Windows 7

I use Windows 7 and am interested in using IPA Extensions through unicode. I understand this requires me to edit my registry, which I am loathe to do. The article is a bit too jargony for my comfort. Is there a trustworthy program I can use to activate unicode? Is there a site that would give step by step instructions on editting the registry? Or am I confused, and is this unnecessary? I am going by my experience with ASCII which allows some non-English characters and accented characters but which does not include any IPA symbols like ʃ, ð, or ŋ. Thanks. μηδείς (talk) 02:14, 27 December 2014 (UTC)[reply]

I couldn't find anything on modifying the registry to make this happen (maybe I'm misunderstanding) what exactly do you want to make your computer do when you say "activating IPA extensions". Something in here [1] may help with using IPA, please let me know if this is not what you're looking for, I'm sure there is a doable solution with minimal risks. :-)Phoenixia1177 (talk) 07:02, 27 December 2014 (UTC)[reply]

Yeah I'm a bit confused by what the OP is trying to achieve and what the current problem is. Windows has been Unicode native since XP or earlier and there's no need to enable it. Application support for Unicode has sometimes been a a bit hit and miss, but it should be fine in any recent decent browser by now (this includes IE, I think since IE 7 or 8). And AFAIK Windows 7 has a decent complement of default IPA supporting fonts [2]. Are many of the characters that μηδείς pasted not working for them? Or many here Phonetic symbols in Unicode (probably showing up as boxes)? If these are rendering fine, then perhaps the problem is data entry. If that's the case there are vaious methods to do that already. For example those in the above link. The wikipedia edit box also lets you enter IPA. Help:Special characters has some info, but I'm not sure if it's useful here. Help:IPA does have some recommendations on checking for possible rendering issues. That (sort of by the font comparisons), the special characters help page (in the IPA section) and Help:IPA for English (under see also) has some font suggestions if the OP isn't happy with whatever ones on their browser. Either way there should almost definitely no need to touch the registry. Nil Einne (talk) 13:09, 27 December 2014 (UTC)[reply]

The problem is that I am ignorant enough of the issue that I am finding it hard to formulate the question. Let's say I am typing a paper in default settings in MS Word using times roman, etc., and I want to use the ð character. I know how to type the ñ character using ASCII. ALT+XXX whatever the code is, since I don't have the numbers for XXX in front of me. I understand that ð will require a four digit hexadecimal code, and am familiar with hexadecimal from the RBG color format. But how would I actually enter the code for it, what keystrokes? If I can do that, then all is well. But for some reason what I have read has implied to me that the registry in windows 7 has to be editted to allow such entries. That latter part may be totally wrong, based on my ignorance and misunderstanding. So, if we go step by step and assume my windows seven laptop is already compatible, what would be the keystrokes to enter the symbol ð, (U+00F0) when simply typing in a blank word document? Thanks for your patience. μηδείς (talk) 00:38, 28 December 2014 (UTC)[reply]

Apparently, windows will type something when you use the alt+, but it need not follow the unicode hex values. I would suggest using one of the programs I linked too - then you don't have to memorize hex numbers. However, to get it so that if you type in Alt+<number in hex form> (you'll need to hold both alt and +) to give the symbol, you may need to add a value to the reg. I'll email you a reg script and instructions to use it, then you don't have to do it manually. (you will need to logout, then back in, for this to take effect - or you can restart the computer).Phoenixia1177 (talk) 04:55, 28 December 2014 (UTC)[reply]

If you want to use Alt codes with Unicode hex values, you do need to edit the registry. Here's a page that shows the steps: Typing Arbitrary Unicode Characters in Windows.

To find the Unicode hex value you need, go to Character Map, click on the character, then look at the bottom status bar. I happened to know ð is called eth, so I used the Advanced View search box to find eth. ð is U+00F0.

Once you know the Unicode hex value you want, careful reading of Wikipedia's Alt code article suggests you would enter it like this:

Make sure Num Lock is on.
Hold down the Alt key.

On the number pad press +.
Press F.
On the number pad press 0.

Release the Alt key.

--Bavi H (talk) 08:12, 28 December 2014 (UTC)[reply]

You do not need edit the registry or anything. You do not need remember any codes. Entering the IPA symbols as simple as that (for Windows):

Download this installation.
Run and wait until it installs.
Add the new layout. Use as any other layout.
If you do not remember or do not want to remember where each character is, use the On-Screen Keyboard.

I've been using this layout already for 10 years.--Lüboslóv Yęzýkin (talk) 10:05, 28 December 2014 (UTC)[reply]

Thanks for all the answers so far and email. I have guests arriving in a few hours and will be busy, so just stopping by to say thanks before I get the time to try the various suggestions. μηδείς (talk) 20:22, 28 December 2014 (UTC)[reply]

TIFF source code capable of reading and writing 16-bit color images

I'm looking for source code (C or C++ preferably), capable of reading and writing TIFF 16-bit color images. I'm aware of Libtiff. However, this library appears to handle only 8-bit color images [3]. Any suggestions? Thanks, --NorwegianBlue^talk 11:38, 27 December 2014 (UTC)[reply]

According to [4] the library should support 16 bit - however, the user manual says that it does not, yet that it does for 24/32 bit. I've never used it, so I'm not sure if there is a typo somewhere - but it might be worth a look.Phoenixia1177 (talk) 11:56, 27 December 2014 (UTC)[reply]

For clarity, I'm fairly sure when the OP refers to 8 bit and 16 bit images, these are referring to the bit depth per channel. For a RGB images 8 bits per channel (well most colour formats without transparency) these will be 24 bit per pixel. For RGBa (i.e. with the alpha channel/transparency) these will be 32 bit per pixel. These are almost definitely the 24/32 bit referred to since 24 or 32 bit per channel image formats are almost unheard of, if they exist. 16 bit per channel images will be 48 or 64 bit per pixel. So there isn't any contradiction with the user manual saying it supports 24/32 bit per pixel but not 16 bit per channel. There may be a contradiction with the site saying it supports 16 but although I don't see it saying that. I only see mention of support for 16 and 48 bit for the PNM plugin which I guesss supports the Netpbm format and a few other formats like PNG as well as generally better support for such formats, but no specific mention of support for 16/48/64 for TIFF. Is it at some other part of the site? Nil Einne (talk) 12:41, 27 December 2014 (UTC)[reply]

From under 3.7.0 "The main additions concern the support for HDR and 48-bit TIFF/PNG images" - which is why I assumed they were talking bit depth in the user manual - there is no 48 listed there, thus, it didn't make sense to me to say they support it, but not even mention it (and, personally, if they're putting down things they don't support, 16 bit depth isn't unreasonable, it seems odds not to include it). --just justifying why I made the assumptions I did.Phoenixia1177 (talk) 13:19, 27 December 2014 (UTC)[reply]

Whoops sorry, I missed that one. Would seem to suggest there may be support. May be checking the libtiff source and comments will help clarify what the status is. Nil Einne (talk) 17:09, 27 December 2014 (UTC)[reply]

Thanks, Phoenixia and Nil! Yes, I was referring to the bit depth per channel. Encouraged by your replies, I downloaded LibTIFF 3.9.7, which with some minor adjustments compiled in Visual Studio Express 2013. I built some of the tools, and did some testing. It turns out that it does support reading 16-bit-per-channel (=48-bit) color images. I haven't checked whether it will read 64-bit RGB+alpha images. With the tool tiffcrop (which does a lot more than cropping), I was able to turn an original upside-down, and concatenate the original and the upside-down image. However, the tiff2bw tool, which generates a black-and-white image from a color TIFF image, failed with an error message about only supporting 8-bit images when given a 16-bit-per channel image, but worked nicely whith ~~a 16-bit image~~ an 8-bit image. So there is support for reading and writing 16-bit-per-channel images. How much support there is for manipulating 16-bit-per-channel images, remains to be seen, when I delve into the difficult part: figuring out the API. Thanks again! --NorwegianBlue^talk 19:41, 27 December 2014 (UTC)[reply]

It works. I was able to read a 16-bit image scanline by scanline, manipulate it (switched red and green channel, just to prove the point), and write the result as a new 16-bit image. I cut and pasted from the code of the tiff2bw tool, which did not contain too much clutter, and modified as necessary. Googling the function names that were used (or "man <functionname>"), was the easiest way of getting information on how the API worked. --NorwegianBlue^talk 13:46, 28 December 2014 (UTC)[reply]

Resolved

One thing you might want to check - some tools that claim to support more than 8 bits per channel are actually reading the wider data but storing it as 8 bits internally. This can fool you into thinking that it's working when it's really just throwing away the low order bits. SteveBaker (talk) 16:09, 28 December 2014 (UTC)[reply]

Thanks, Steve. I'll double-check, though in this case I'm fairly certain the whole bit-depth is actually used. I get a 6-byte per pixel buffer in, and write a six-byte per pixel out. But I'll check histograms, to verify there are no gaps. --NorwegianBlue^talk 22:42, 28 December 2014 (UTC)[reply]