Unusual character instead of an apostrophe

I'm noticing an unusual character appearing in my playlist within Exile where an apostrophe should be. How can I fix it?
Screenshot:
Last edited by graysky (2009-08-09 12:56:57)

jbusch wrote:
Gandering a guess, but maybe you don't have the right fonts installed?
http://wiki.archlinux.org/index.php/Fonts
I think I'm set w/ fonts... do you see anything obvious that is missing:
$ pacman -Qs font
local/artwiz-fonts 1.3-4
This is set of (improved) artwiz fonts.
local/fluidsynth 1.0.9-1
A real-time software synthesizer based on the SoundFont 2 specifications.
local/fontcacheproto 0.1.2-2
X11 font cache extension wire protocol
local/fontconfig 2.6.0-2
A library for configuring and customizing font access
local/fontsproto 2.0.2-2
X11 font extension wire protocol
local/freetype2 2.3.9-2
TrueType font rendering library
local/gsfonts 8.11-5
Ghostscript standard Type1 fonts
local/lib32-fontconfig 2.6.0-2 (lib32)
A library for configuring and customizing font access
local/lib32-freetype2 2.3.9-2 (lib32)
TrueType font rendering library
local/libfontenc 1.0.4-2
X11 font encoding library
local/libxfont 1.4.0-1
X11 font rasterisation library
local/libxfontcache 1.0.4-2
X11 font cache library
local/libxft 2.1.13-1
FreeType-based font drawing library for X
local/t1lib 5.1.2-2
Library for generating character- and string-glyphs from Adobe Type 1 fonts
local/ttf-bitstream-vera 1.10-6
Bitstream vera fonts
local/ttf-cheapskate 2.0-6
TTFonts collection from dustimo.com
local/ttf-dejavu 2.29-1
Font family based on the Bitstream Vera Fonts with a wider range of characters
local/ttf-ms-fonts 2.0-2
Core TTF Fonts from Microsoft
local/xorg-font-utils 7.4-2
X.Org font utilities
local/xorg-fonts-100dpi 1.0.1-2 (xorg)
X.org 100dpi fonts
local/xorg-fonts-75dpi 1.0.1-2 (xorg)
X.org 75dpi fonts
local/xorg-fonts-alias 1.0.1-2
X.org font alias files
local/xorg-fonts-encodings 1.0.2-3
X.org font encoding files
local/xorg-fonts-misc 1.0.0-4
X.org misc fonts
Last edited by graysky (2009-08-09 14:37:32)

Similar Messages

Simple key stroke to insert a prime symbol instead of an apostrophe?

Is there a simple key stroke that you can to insert a prime character instead of an apostrophe when your prefrerence is set for "smart quotes" so that you don't have to re-set your preferences???

Welcome to Apple Support Communities.
"Simple"? Not exactly...
This older discussion details the steps to use Unicode entry.
https://discussions.apple.com/thread/1899290?start=0&tstart=0
Open , System Preferences, Hardware, Keyboard allows you to check the box, 'Show Keyboard and Character Viewer in menu bar'. This step gives you quick access to your chosen Keyboard defaults in the menubar.
Open , System Preferences, Personal, Language & Text, to checkmark the Unicode Hex Input box. This permits you to use Unicode for quick(er) special character entry, provided you know the hex equivalent of the desired character(s), listed in the character tables.
With the Unicode Hex Input enabled, hold down the alt/option key and type 2032 (the Unicode decimal number) for the prime symbol ′.
Within the Characters table, save your favorites by clicking the 'gear' button at the bottom left of the Character table, then you can quickly find them and press the 'insert' button in the lower right.
Note that the prime character appearance changes with the font in use, and probably is not available in every font.

Printing '#' character instead of any arabic character

Hello all,
I managed to install apache fop for printing on my Apex instance 4.0.2 to print in pdf,my application is in arabic,when I print all Arabic characters are represented with '#' sign instead of the character itself in the pdf file!!!!!
I think apache fop is not recognizing the Arabic characters,how can I resolve this?
Thanks

You could try using check boxes. See these for details:
Check box not shown
http://blogs.oracle.com/xmlpublisher/entry/wherere_my_checkboxes
or if you have image files for the checkmark box, then you can conditionally display them..
Thanks,
Bipuser

Equivalent of inputting an Integer but a character instead?

Hi,
If I wanted to input a number/integer i could use the following:
Scanner s = new Scanner(System.in);
int time= s.nextInt();
How would I do the same if I wanted to input a character?
If I wanted to input a string what do i change?
many thanks for your help..
Yash

Doesn't that convert the integer into character or something using the ASCII tables?
I probably misunderstood what you're trying to say. Basically I want to enter the character 'B' and assign it to a varialbe at the command prompt and then afterwards I want to enter the String 'Hello' at the prompt and have it assigned to a variable. How would I do that?
System.out.println("please enter character");
System.out.println("please enter String");
I'm reading through the Java book by Walter Savith and the guy uses his own way of reading them in (Savitch.readLine() ), but I want to use the real Java method, which is why i'm stuck;)
thanks again..
Yash

LiveOffice character objects starts with apostrophe

Hi
Using XI3.1 FP 1.8.
When building a universequery in LiveOffice using objects that is defined in the DB as character, the columnvalues in Excel starts with a leading aposthrophe. Ex Costcenterdimension with values 100, K300 , LiveOffice returns in Excel as '100, 'K300.
Is this by design in LiveOffice, that it treats objects that is characterobjects this way? I wouldnt like the the leading aposthrophe, because it affects formulas in Excel.
When converting the objects to integer in the universe, everything is fine. But if the object is like my example with CostCenterdimension (values 100 or value K300 ) then I cant convert those (K300) that have a alphadigit.
Any insight into this matter would be appriciated
//Björn

Nicos82 wrote:
Ok thanks a lot.
So you confirm that problem isn't related to database character set. And so we have no Oracle storage problems. This is a good info for me !
I checked server environment variables and it seems that NLS_LANG is not set at all.
Honestly I don't know what else checking more....
I'm going to be confused.do you have data storage problem (incorrect characters in the DB) or
do you have data presentation problem (client software can't handle Polish characters)?
use DUMP or ASCIISTR function to inspect the content in the DB

Firefox displays &#8217 instead of an apostrophe. How do I fix this?

and left quote marks as &#8220 etc etc

Hello pjmelli921,
You have to locate the album in itunes. Highlight each track, hold the ctrl button and left click each one.
Do a right-click on the highlighted blue, select get info, say yes to editing multiple tracks.
Hit the options tab, change "part of a compliation" to yes, select ok on the bottom right.
Resync ipod. This should fix it on your ipod after the resync.
Hope this helps.
~Julian

I find that entering "m" on the keyboard often deletes the previous typed character instead

Anyone know how to submit this as a bug/feature report to Apple for consideration of potential changes as a future improvement in iOS implementation?
Thanks
PS This site is a bit out of date - iPhone 5s, iOS 7.1

You are very perceptive, and this is indeed the reason. However, the delete button is both larger than normal buttons and very close to the "m" - offering the possiblity of increasing the space between them to reduce the potential interference. Grown up fingers are large and the keyboard is small.
Many people I have spoken to have the same problem either frequently or intermittently.
This is certainly an "avoidable feature", which I would like to suggest that Apple could consider improving. Hence my question, which was not actually looking for an explanation but asking how I could make the suggestion directly to Apple.
But thanks for your input.

Apostrophes trigger weird backspace behavior in Mail

I upgraded to Mavericks a couple of days ago, and since then I've had the weirdest and most annoying problem in my Mail app (and ONLY in my Mail app):
If I type a contraction ending in "re", (example: we're, they're), the spacebar sends the cursor back one character instead of adding a space after the word. So, it deposits the cursor back beteween the "re".
If I form a contraction with any other letter combination (I'll, he'd, it's), the spacebar does nothing on the first strike. I have to hit it twice to get a space after the word. At all other times, the spacebar functions normally.
I've tried turning off spelling checks on my global keyboard preferences, and on Mail.app preferences; I've tried restarting the app and my MacBook. Nothing helps. And since I'm not a very formal writer, it bites me in the *** approximately seventy thousand times a day.
Is there any way to cure this disease?

Are you sure that the "smart quotes" box really fixed the problem? I have the same problem, but what happens is that when I type an apostrophe, it is at first a straight apostrophe, until I hit the space bar after the word in which I used it, at which time the straight apostrophe turns into a "smart" (i.e., slanted) apostrophe, and the cursor jumps back to the end of the word that was just autocorrected from straight to smart apostrophe.
Turning off smart quotes indeed prevents the backspace, but it does so by *not* turning the straight apostrophe into a slanted apostrophe. So yeah, it prevents the annoying backspace, but at the cost of functionality. How has apple not fixed this after all these months? Does mail just not misbehave this way for most people?

Apostrophes are replaced by question marks in output string?

Hi Guys
I think this is an encoding problem but I cannot find it in the forum archives. My apostrophes are being replaced by question marks on my jsp output?
Any idea why and how to get them back to apostrophes
Cheers, ADC

Guys, the 3rd party product has no trouble at all
showing the apostrophes from the self-same database
that I get question marks from.
This MUST be an encoding issue, so anyone that knows
about encoding and changing it please could you
suggest something. You can take for granted that one
way or another the character in the database IS an
apostrophe as verified by viewing it via the 3rd party
product we have.You said...
In the SQL database view they come out as squares
Were you referring to the normal applications that are available for viewing data for the database (like SQL*Plus or Enterprise Manager?)
If yes, then if it was me then I would presume it was not an apostrophe and that the third party tool was mapping the real character to an apostrophe. A 'square' indicates an unusual character in viewers.
Are you using EBCDIC? Unless EBCDIC is involved apostrophe has the same value in most if not all character sets because ANSI forms the lower range for most character sets. I know for example that Korean, Japanese and Chinese character sets use ANSI, as does unicode (with padded zeros for the wider ranges.)

Apostrophe HTML code

I subscribe to the following podcast:
feed://www.collegedalechurch.com/downloads/CollegedaleChurchSermons.xml
All of the titles and descriptions that contain "curly" apostrophe characters show up as their decimal code [ampersand pound 146 semicolon] instead of the apostrophe character intended. Is there a way to correct this issue with iTunes or will the podcaster need to modify their way of publishing?
I tried to search for this topic but I could not find anything. Thanks in advance for your help.
MacBook Pro 17" Mac OS X (10.4.9) iTunes 7.1.1
MacBook Pro 17" Mac OS X (10.4.9) iTunes 7.1.1

Actually, iTunes doesn't handle HTML at all for podcast titles or descriptions. It's stated in the iTunes Store podcast technical specifications that they don't. I ran the feed through FeedValidator.org, and it appears that the way they used the code for the character is invalid, which is why it isn't showing up properly. You might want to contact the publisher about it.

Problem with backtick replacing apostroph in applescript/shell script

I've got a script that appears to be using a backtick instead of an apostrophe which is causing an error in my shell script. For the life of me I can't seem to find where the error is being generated?
The script is attached below. I'm using Exiftool, an app that writes metadata to image files. The shell script
set cmd to "exiftool -CopyrightNotice=" & exifCopyright & " " & thisFilePath & ""
set theResult to do shell script cmd
works fine but the following shell script
set cmd to "exiftool" & space & authorStr & " " & thisFilePath & ""
set theResult to do shell script cmd
returns the error "sh: -c: line 0: unexpected EOF while looking for matching `''
sh: -c: line 1: syntax error: unexpected end of file" number 2. The code in the event log in applescript editor looks exactly the same to me but one fails in the shell script.
It has been suggested by the developer of Exiftool, Phil Harvey, that there is a backtick in the second shell script. I read somewhere in the applescript docs that this is due to a change in OS 10.6? Any suggestions on how to fix this?
Thanks.
Pedro

Yea, the authorStr value has a space like "Joe Smith"
Then you need to use quoted form of this string, too:
set cmd to "exiftool " & quoted form of authorStr & space & thisFilePath
although the format looks wrong to me - shouldn't there be some kind of switch, such as "-author=' before it?
You have to consider how you'd enter this at the command line to work out how best to translate it to AppleScript. For example, if the command line version were:
exiftool -author='John Doe' /path/to/some.jpg
you can see the quotes are around the name, not the entire -author switch. In this case you should be looking at something like:
set authorStr to "John Doe"
set theFilePath to "/path/to/some.jpg"
set theCmd to "exiftool -author=" & quoted form of authorStr & space & quoted form of theFilePath
Now you could, of course, use quoted form when you create the variables (e.g. set authorStr to quoted form of "John Doe"), but that may screw you up later on if/when you try to use authorStr in some other way, so I find it best to use quoted form only where it's needed.

What every developer should know about character encoding

This was originally posted (with better formatting) at Moderator edit: link removed/what-every-developer-should-know-about-character-encoding.html. I'm posting because lots of people trip over this.
If you write code that touches a text file, you probably need this.
Lets start off with two key items
1.Unicode does not solve this issue for us (yet).
2.Every text file is encoded. There is no such thing as an unencoded file or a "general" encoding.
And lets add a codacil to this – most Americans can get by without having to take this in to account – most of the time. Because the characters for the first 127 bytes in the vast majority of encoding schemes map to the same set of characters (more accurately called glyphs). And because we only use A-Z without any other characters, accents, etc. – we're good to go. But the second you use those same assumptions in an HTML or XML file that has characters outside the first 127 – then the trouble starts.
The computer industry started with diskspace and memory at a premium. Anyone who suggested using 2 bytes for each character instead of one would have been laughed at. In fact we're lucky that the byte worked best as 8 bits or we might have had fewer than 256 bits for each character. There of course were numerous charactersets (or codepages) developed early on. But we ended up with most everyone using a standard set of codepages where the first 127 bytes were identical on all and the second were unique to each set. There were sets for America/Western Europe, Central Europe, Russia, etc.
And then for Asia, because 256 characters were not enough, some of the range 128 – 255 had what was called DBCS (double byte character sets). For each value of a first byte (in these higher ranges), the second byte then identified one of 256 characters. This gave a total of 128 * 256 additional characters. It was a hack, but it kept memory use to a minimum. Chinese, Japanese, and Korean each have their own DBCS codepage.
And for awhile this worked well. Operating systems, applications, etc. mostly were set to use a specified code page. But then the internet came along. A website in America using an XML file from Greece to display data to a user browsing in Russia, where each is entering data based on their country – that broke the paradigm.
Fast forward to today. The two file formats where we can explain this the best, and where everyone trips over it, is HTML and XML. Every HTML and XML file can optionally have the character encoding set in it's header metadata. If it's not set, then most programs assume it is UTF-8, but that is not a standard and not universally followed. If the encoding is not specified and the program reading the file guess wrong – the file will be misread.
Point 1 – Never treat specifying the encoding as optional when writing a file. Always write it to the file. Always. Even if you are willing to swear that the file will never have characters out of the range 1 – 127.
Now lets' look at UTF-8 because as the standard and the way it works, it gets people into a lot of trouble. UTF-8 was popular for two reasons. First it matched the standard codepages for the first 127 characters and so most existing HTML and XML would match it. Second, it was designed to use as few bytes as possible which mattered a lot back when it was designed and many people were still using dial-up modems.
UTF-8 borrowed from the DBCS designs from the Asian codepages. The first 128 bytes are all single byte representations of characters. Then for the next most common set, it uses a block in the second 128 bytes to be a double byte sequence giving us more characters. But wait, there's more. For the less common there's a first byte which leads to a sersies of second bytes. Those then each lead to a third byte and those three bytes define the character. This goes up to 6 byte sequences. Using the MBCS (multi-byte character set) you can write the equivilent of every unicode character. And assuming what you are writing is not a list of seldom used Chinese characters, do it in fewer bytes.
But here is what everyone trips over – they have an HTML or XML file, it works fine, and they open it up in a text editor. They then add a character that in their text editor, using the codepage for their region, insert a character like ß and save the file. Of course it must be correct – their text editor shows it correctly. But feed it to any program that reads according to the encoding and that is now the first character fo a 2 byte sequence. You either get a different character or if the second byte is not a legal value for that first byte – an error.
Point 2 – Always create HTML and XML in a program that writes it out correctly using the encode. If you must create with a text editor, then view the final file in a browser.
Now, what about when the code you are writing will read or write a file? We are not talking binary/data files where you write it out in your own format, but files that are considered text files. Java, .NET, etc all have character encoders. The purpose of these encoders is to translate between a sequence of bytes (the file) and the characters they represent. Lets take what is actually a very difficlut example – your source code, be it C#, Java, etc. These are still by and large "plain old text files" with no encoding hints. So how do programs handle them? Many assume they use the local code page. Many others assume that all characters will be in the range 0 – 127 and will choke on anything else.
Here's a key point about these text files – every program is still using an encoding. It may not be setting it in code, but by definition an encoding is being used.
Point 3 – Always set the encoding when you read and write text files. Not just for HTML & XML, but even for files like source code. It's fine if you set it to use the default codepage, but set the encoding.
Point 4 – Use the most complete encoder possible. You can write your own XML as a text file encoded for UTF-8. But if you write it using an XML encoder, then it will include the encoding in the meta data and you can't get it wrong. (it also adds the endian preamble to the file.)
Ok, you're reading & writing files correctly but what about inside your code. What there? This is where it's easy – unicode. That's what those encoders created in the Java & .NET runtime are designed to do. You read in and get unicode. You write unicode and get an encoded file. That's why the char type is 16 bits and is a unique core type that is for characters. This you probably have right because languages today don't give you much choice in the matter.
Point 5 – (For developers on languages that have been around awhile) – Always use unicode internally. In C++ this is called wide chars (or something similar). Don't get clever to save a couple of bytes, memory is cheap and you have more important things to do.
Wrapping it up
I think there are two key items to keep in mind here. First, make sure you are taking the encoding in to account on text files. Second, this is actually all very easy and straightforward. People rarely screw up how to use an encoding, it's when they ignore the issue that they get in to trouble.
Edited by: Darryl Burke -- link removed

DavidThi808 wrote:
This was originally posted (with better formatting) at Moderator edit: link removed/what-every-developer-should-know-about-character-encoding.html. I'm posting because lots of people trip over this.
If you write code that touches a text file, you probably need this.
Lets start off with two key items
1.Unicode does not solve this issue for us (yet).
2.Every text file is encoded. There is no such thing as an unencoded file or a "general" encoding.
And lets add a codacil to this – most Americans can get by without having to take this in to account – most of the time. Because the characters for the first 127 bytes in the vast majority of encoding schemes map to the same set of characters (more accurately called glyphs). And because we only use A-Z without any other characters, accents, etc. – we're good to go. But the second you use those same assumptions in an HTML or XML file that has characters outside the first 127 – then the trouble starts. Pretty sure most Americans do not use character sets that only have a range of 0-127. I don't think I have every used a desktop OS that did. I might have used some big iron boxes before that but at that time I wasn't even aware that character sets existed.
They might only use that range but that is a different issue, especially since that range is exactly the same as the UTF8 character set anyways.
>
The computer industry started with diskspace and memory at a premium. Anyone who suggested using 2 bytes for each character instead of one would have been laughed at. In fact we're lucky that the byte worked best as 8 bits or we might have had fewer than 256 bits for each character. There of course were numerous charactersets (or codepages) developed early on. But we ended up with most everyone using a standard set of codepages where the first 127 bytes were identical on all and the second were unique to each set. There were sets for America/Western Europe, Central Europe, Russia, etc.
And then for Asia, because 256 characters were not enough, some of the range 128 – 255 had what was called DBCS (double byte character sets). For each value of a first byte (in these higher ranges), the second byte then identified one of 256 characters. This gave a total of 128 * 256 additional characters. It was a hack, but it kept memory use to a minimum. Chinese, Japanese, and Korean each have their own DBCS codepage.
And for awhile this worked well. Operating systems, applications, etc. mostly were set to use a specified code page. But then the internet came along. A website in America using an XML file from Greece to display data to a user browsing in Russia, where each is entering data based on their country – that broke the paradigm.
The above is only true for small volume sets. If I am targeting a processing rate of 2000 txns/sec with a requirement to hold data active for seven years then a column with a size of 8 bytes is significantly different than one with 16 bytes.
Fast forward to today. The two file formats where we can explain this the best, and where everyone trips over it, is HTML and XML. Every HTML and XML file can optionally have the character encoding set in it's header metadata. If it's not set, then most programs assume it is UTF-8, but that is not a standard and not universally followed. If the encoding is not specified and the program reading the file guess wrong – the file will be misread.
The above is out of place. It would be best to address this as part of Point 1.
Point 1 – Never treat specifying the encoding as optional when writing a file. Always write it to the file. Always. Even if you are willing to swear that the file will never have characters out of the range 1 – 127.
Now lets' look at UTF-8 because as the standard and the way it works, it gets people into a lot of trouble. UTF-8 was popular for two reasons. First it matched the standard codepages for the first 127 characters and so most existing HTML and XML would match it. Second, it was designed to use as few bytes as possible which mattered a lot back when it was designed and many people were still using dial-up modems.
UTF-8 borrowed from the DBCS designs from the Asian codepages. The first 128 bytes are all single byte representations of characters. Then for the next most common set, it uses a block in the second 128 bytes to be a double byte sequence giving us more characters. But wait, there's more. For the less common there's a first byte which leads to a sersies of second bytes. Those then each lead to a third byte and those three bytes define the character. This goes up to 6 byte sequences. Using the MBCS (multi-byte character set) you can write the equivilent of every unicode character. And assuming what you are writing is not a list of seldom used Chinese characters, do it in fewer bytes.
The first part of that paragraph is odd. The first 128 characters of unicode, all unicode, is based on ASCII. The representational format of UTF8 is required to implement unicode, thus it must represent those characters. It uses the idiom supported by variable width encodings to do that.
But here is what everyone trips over – they have an HTML or XML file, it works fine, and they open it up in a text editor. They then add a character that in their text editor, using the codepage for their region, insert a character like ß and save the file. Of course it must be correct – their text editor shows it correctly. But feed it to any program that reads according to the encoding and that is now the first character fo a 2 byte sequence. You either get a different character or if the second byte is not a legal value for that first byte – an error.
Not sure what you are saying here. If a file is supposed to be in one encoding and you insert invalid characters into it then it invalid. End of story. It has nothing to do with html/xml.
Point 2 – Always create HTML and XML in a program that writes it out correctly using the encode. If you must create with a text editor, then view the final file in a browser.
The browser still needs to support the encoding.
Now, what about when the code you are writing will read or write a file? We are not talking binary/data files where you write it out in your own format, but files that are considered text files. Java, .NET, etc all have character encoders. The purpose of these encoders is to translate between a sequence of bytes (the file) and the characters they represent. Lets take what is actually a very difficlut example – your source code, be it C#, Java, etc. These are still by and large "plain old text files" with no encoding hints. So how do programs handle them? Many assume they use the local code page. Many others assume that all characters will be in the range 0 – 127 and will choke on anything else.
I know java files have a default encoding - the specification defines it. And I am certain C# does as well.
Point 3 – Always set the encoding when you read and write text files. Not just for HTML & XML, but even for files like source code. It's fine if you set it to use the default codepage, but set the encoding.
It is important to define it. Whether you set it is another matter.
Point 4 – Use the most complete encoder possible. You can write your own XML as a text file encoded for UTF-8. But if you write it using an XML encoder, then it will include the encoding in the meta data and you can't get it wrong. (it also adds the endian preamble to the file.)
Ok, you're reading & writing files correctly but what about inside your code. What there? This is where it's easy – unicode. That's what those encoders created in the Java & .NET runtime are designed to do. You read in and get unicode. You write unicode and get an encoded file. That's why the char type is 16 bits and is a unique core type that is for characters. This you probably have right because languages today don't give you much choice in the matter.
Unicode character escapes are replaced prior to actual code compilation. Thus it is possible to create strings in java with escaped unicode characters which will fail to compile.
Point 5 – (For developers on languages that have been around awhile) – Always use unicode internally. In C++ this is called wide chars (or something similar). Don't get clever to save a couple of bytes, memory is cheap and you have more important things to do.
No. A developer should understand the problem domain represented by the requirements and the business and create solutions that appropriate to that. Thus there is absolutely no point for someone that is creating an inventory system for a stand alone store to craft a solution that supports multiple languages.
And another example is with high volume systems moving/storing bytes is relevant. As such one must carefully consider each text element as to whether it is customer consumable or internally consumable. Saving bytes in such cases will impact the total load of the system. In such systems incremental savings impact operating costs and marketing advantage with speed.

I am getting strange numeric symbols or tiles instead of text when using Firefox. Repeated reloads and virus scans have not fixed it. I can't find a patch. Help! I hate IE!

Each time I open Firefox, I get blocks or tiles of numbers for each character instead of text. The tiles appear as composites of four digits, stacked two by two. At some websites, normal text does appear in boxes but mostly as this numeric gibberish. The functionality of the Firefox software does not seem to have been affected. But if I can't read it, I can't use it.

Try to set the pref gfx.font_rendering.directwrite.use_gdi_table_loading to false on the about:config page.
To open the about:config page, type about:config in the location (address) bar and press the "Enter" key, just like you type the url of a website to open a website. 
If you see a warning then you can confirm that you want to access that page. 
*Use the Filter bar at to top of the about:config page to locate a preference more easily.
*Preferences that have been modified show as bold(user set).
*Preferences can be reset to the default or changed via the right-click context menu.

Report not output ENGLISH character

hi,
im using 12.1.3,
recently just did a customization report. but the report not output in English character, instead it outputs in Greek or Symbol font in PDF.
i can see the ENGLISH output if i run it in REPORT BUILDER.
my app server is RED HAT 5. I have configured the printer correctly
anything that i need to configure?

Hi;
Please check below notes:
How to Setup Pasta Quickly and Effectively [ID 356501.1]
Also see:
R12-Pasta option
PASTA FOR R12
Regard
Helios

Character coersion

I have an interesting problem, using JSTL 1.1.2. I have a bean method which provides a Map of Character objects, like this:
private Map myMap;
...snip...
 Character myChar = new Character('X');
 myMap.put("hello",myChar);
...snip...
public Map getMap() {
 return myMap;
}Now, I can display any part of the map simply in JSTL:
Value is : ${somebean.map['hello']}which works just fine and displays the Character value of X correctly.
HOWEVER... when I try and compare the character to a constant value...:
<c:if test="${somebean.map['hello'] == 'X'}">Something.</c:if>...then I get a runtime exception:
javax.servlet.jsp.el.ELException: An exception occured trying to convert String "X" to type "java.lang.Long"Why is it trying to convert the constant value 'X' to a Long? What can I do to make it convert it to a Character instead so that it does the comparison properly?
I have tried using eq instead of == but this makes no difference.

I cannot change the underlying map class. It is being used to represent a record in a table in an Oracle database - Characters represent char columns, Strings for varchars, Doubles for numbers, etc. I need to be able to pass single character values, whether they be char primitives or Character objects, between the bean and JSTL.
JSTL is apparently coercing my Character objects to Long objects before attempting to compare them to a String constant. Wouldn't it be more logical to attempt to coerce the String constant into a Character? Is there any way to obtain this behaviour and override the Long conversion?

Unusual character instead of an apostrophe

Similar Messages

Maybe you are looking for