Accented Characters and Diacritic folding flag

Hi,
When using "--diacritic-folding" flag in dgidx, is there a way to ignore certain characters from mapping accented characters to simple ASCII equivalents?
For e.g, i have this flag enabled but i need "ñ" and "n"to behave as two different characters.
Is this possible?
Thanks
Edited by: mk.s on Apr 12, 2013 5:33 AM

There is no out of the box capability for this that I am aware of. You could raise a feature request via support.oracle.com to allow you to be able to define exceptions, and if you do so I'd recommend including some use cases to explain the business requirement.
The only way I can think of doing this with the current software is a workaround - you would have to have a pre-processing step to map the character to a different code point, then when you submit your search apply the same translation. I've done this previously to get around issues with unsupported (in older Endeca releases) code points in the Thai language, and it does work but you have to add a manipulator to your pipeline (or do the transformation in the data extract) and have some simple code before you send the query on to Endeca (before ENEQuery if via the API).
Thanks
Michael

Similar Messages

[Solved] Greek accented characters and Qt Applications

Hello.
This is my first day with Arch linux.
My problem has to do with greek accented characters like ά, ή, ό etc.
I can type these characters on my browsers, rox file manager and other applications but not on Qt based applications like Skype and TeXmaker.
At first when I tried to type ά on skype I got nothing.
Later I installed ibus-qt and now I get á instead of ά, é instead of έ, etc.
Thanks in advance for any help.
PS: I include the results of locale -a and locale commands in case it helps:
# locale -a
C
POSIX
el_GR
el_GR.iso88597
el_GR.utf8
en_US
en_US.iso88591
en_US.utf8
greek
# locale
LANG=C
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=
Last edited by Paris (2013-07-22 00:41:19)

I just created a /etc/rc.conf file and added:
HARDWARECLOCK="UTC"
TIMEZONE="Europe/Athens"
KEYMAP="us"
CONSOLEFONT="ter-v16b" #it's Terminus font for console, just install terminus-font from community
CONSOLEMAP=
LOCALE="en_US.UTF-8"
DAEMON_LOCALE="no"
USECOLOR="yes"
This fixed my problem.

Accented characters and UTF-8

Hi all,
I have a problem with accented characters. I read that Plumtree 5.0 is completely Unicode enabled and all HTTP responses from remote web services are converted to Unicode (UTF-16). So the portal sends back to the client browser all pages in UTF-8.
We have a lots of portlet (ASP and JSP) that write data in external DB, for example SQLServer. When I fill an html form with accented characters that have to be saved in our DB, they are saved in UTF-8 because the gateway converts the HTTP response. We want that the data are saved as if we don't use the portal (without conversion). I tried to change the Charset with the ASP code (Response.Charset). This solves only the problem of displaying the right characters in the browser.
Could you explain me better how the portal make the conversion and how can I solve my problem?
Thank you very much,
Alberto Marchiaro

It might be helpful to clarify a few things first: 1. Both Java and VB Script will store strings in UTF-16/Unicode. If you have some code in your ASP file that looks like this: Dim strDatastrData = Request.Form("SomeName") then if you were to examine memory for the variable strData, you would see 16 bit characters. The same is true for Java. 2. String data is almost never sent over HTTP as UTF-16/Unicode. 3. Both Java and VBScript perform an implicit character set transcoding when reading string data out of a request or when writing string data out to a response. 4. ASP will perform the transcoding according to the value of the Session.CodePage value. If you have Session.CodePage to 65001, then ASP will expect the string data to be in UTF-8 and it will transcode UTF-8 in the request into UTF-16 in VB Script. Similarly, a Session.CodePage value of 65001 will cause "Response.Write" to convert UTF-16/Unicode into UTF-8. 5. All of the above is separate from how Java or VB Script interact with the database. Generally speaking an ASP module will use ODBC to communicate with the database. The ODBC layer knows that VB Script keeps strings in UTF-16/Unicode. The ODBC layer will perform the proper conversion into the database character set. Plumtree always recommends using UTF-16/Unicode in the database. You can do this relatively easily by declaring your database columns using the "N" datatypes such as NCHAR and NVARCHAR. However even if you using some other character set, the ODBC layer should always properly transcode from VBScript. The importantly thing to remember is that data that is sent over HTTP is never written directly to the database without going through some ASP or JSP code. Since the ASP and JSP code always uses UTF-16/Unicode, there should never be any issue with how the data is sent over HTTP. Here is an explanation for how Session.CodePage, Response.CharSet and Session.LCID work in ASP:****************************************************
1. Response.CharSet
2. Session.CodePage
3. Session.LCID
Here is an explanation of these properties and why they are important to non-English ASP gadget writers:
1. Response.CharSet
This property will cause the HTTP contentType header to be set with the specified character set. The HTTP header is the best way to tell the recipient what the character set is. The Plumtree HTTPGadgetProvider will read the ContentType header and then know how to properly trancode the portlet text into UTF-16/Unicode. Here
is an example of how to set this property:
Response.CharSet = "UTF-8"
2. Session.CodePage
This property tells the ASP engine which character set to send text in. Please remember that all text is encoded in Unicode on the Web Server. It only gets turned into the client character set when it is send down to the client. The Session.CodePage tells the engine which codepage to transcode into when sending down to the client. Please note that this property is an "integer" property not a string. So you have to know the number of the codepage that you would like to transcode into. Here is an example of how to use this property:
Session.CodePage = 65001
3. Session.LCID
This property tells the ASP engine which locale is being used. The locale is used by various VBScript functions such as FormatDateTime in order to format the date correctly for the locale. If the locale is a French locale, then the date will be formatted according to French rules. The locale does not really effect the character set, but if the portlet writer is going to the trouble of setting the other properties, then they should also set the LCID too. Here is an example of how to set this property:
Session.LCID = 1041
Please note that the examples that I am using are the appropriate examples for Japanese and UTF-8. The values for these properties are different for different character sets. For example, for ISO-2022-JP, the values would be:
Request.CharSet = "iso-2022-jp"
Session.CodePage = 50220
Session.LCID = 1041
A very helpful URL to figure out the values to use with Request.CharSet and Session.CodePage is the following:
http://msdn.microsoft.com/library/default.asp?url=/workshop/Author/dhtml/reference/charsets/charset4.asp

Accented characters showing up as ? in JRE1.3 but ok in 1.2

I'm implementing a database web interface product that utilizes JSPs (on SunOS 5.7).
The problem is in the search form. When using accented characters (French language), the JSP calls on URLEncode, but all accented characters show up as '?'.
However, when editing a record, using accented characters is not a problem (i.e., the accented characters are properly stored in the fields).
Back on the server, I ran a small program to output accented characters and also to call java.net.URLEncoder to convert the characters.
The default JDK is J2SE (1.3.1). Compiliing and running the program results in question marks.
Using JDK 1.2, the accented characters show up fine.
It would appear that URLEncoder is not at fault, but instead, JDK 1.3.1 doesn't seem to handle the accented characters.
I figure there must be a setting somewhere, but I'm not sure where.
Here's the program I used (written in Win98, using standard Win-based character set and Unicode format \u00xx; in Unix, "more" displays the Win accented characters fine but "vi" displays them as \xxx; compiles and displays perfectly when using JDK 1.2):
import java.net.*;
class mine {
public static void main(String args[]) {
System.out.println("��") ;
System.out.println(URLEncoder.encode("��")) ;
System.out.println("\u00e0\u00e2\u00e4");
System.out.println("\351");
System.out.println("\351\347\356\364\373\340\350\342\344\374\357") ;
The output with JDK 1.2 is:
��
%E9%E7%EE%F4%FB%E0%E8%E2%E4%FC%EF
��
The output with JDK 1.3.1 is:
%3F%3F%3F%3F%3F%3F%3F%3F%3F%3F%3F

Between jdk1.2 and jdk 1.3 the default encoding of the vm changed.
You can get it by executing:
System.out.println("Default Encoding:" + System.getProperty("file.encoding"));
or
System.out.println("Default Encoding:" + (new java.io.InputStreamReader(System.in)).getEncoding());
The default encoding is used during the conversion of bytes to strings and vice verca.
Assume your default encoding is ISO8859_1. Then calling new String(byte[]) is equivalent to calling
new String(byte[], "ISO8859_1")
Now if you are converting a character from one encoding scheme to another and there is no mapping
for this character in the target scheme. Then the character will be replaced by a default character
which is (quite often) the question mark.
You can set the default encoding for a vm by passing it as a command line parameter
java -Dfile.encoding=ISO8859_1
java -Dfile.encoding=Cp1252

Issue with ENEQuery java api and searching terms with accented characters

Hi,
we are using ENEQuery to query the mdex engine. When search terms contain accented characters (like á,í etc), even though the terms are decoded (using java.net.URLDecoder), the term gets send to dgraph is encoded. for e.g a search for "sofá", from the dgraph logs "sof%c3%a1" and fetch in 0 results
ENEQuery query = new ENEQuery();
final ERecSearchList searches = new ERecSearchList();
final ERecSearch eRecSearch = new ERecSearch("search interface name", "term");
searches.add(eRecSearch);
query.setNavERecSearches(searches);
Any suggestions?
Thanks

Hi,
Does your indexed data (which you hope to match) contain "sofá" or "sofa" (no diacritic)? If the latter, and in-general, you may benefit from the dgidx flag --diacritic-folding* as described in documentation "Mapping accented characters to unaccented characters". If you are running the latest version, this is all that should be required to generate a match.
Best
Brett

I need a Vietnamese keyboard. Recommendations? A keyboard that officially works with iPad and displays all the characters and their accent marks for typing.

Where do I find an excellent and reliable Vietnamese keyboard for new iPad? A keyboard that displays all the characters and the accent marks so typing can be easily accomplished. The iPad keyboard selection for Vietnamese really only seems to change the Return key to the Vietnamese language. iPad is sold all over the world....my interest is Viet Nam.....the full keyboard.

Thanks.....my Vietnamese expert spouse says this tip will work just fine. I was not aware of the hold down function. Slow typing but accomplishes the objective native on the iPad.
You are correct.....most Apps that I find seem to be based only on a copy/paste method of input.
You solved the problem.

Accented characters on E70

Does anyone know if there's an easy way to input accented characters (like é en ä) on the E70 with the phone folded open? I would have expected that switching to Dutch would change the input mode such that pressing for instance e and ' consecutively would give an é, but no such luck. Right now, the only way of entering accented characters that I know of using the full keyboard is holding the control key while pressing the ascii code of the desired character, which is inconvenient even for the few characters for which I know the ascii code by heart. Alternatively, one can close the full keyboard and use the numerical keypad to cycle through the available characters, but constantly switching between the full keyboard and the numerical keyboard is'n really my idea of convenient text input. Thanks, René (that would be Ren<CTRL><233> :-) )

The capitalization help is a feature I'd like to turn off.
It hinders me a lot more than it helps.
The first line of any SMS or email I send always begins with a lowercase letter - very unprofessional - because the UI has already pressed the shift key. When I press the shift key, to capitalize, it un-capitalizes for me.
I can't correct this habit of hitting the shift key each time I want to capitalize a letter - no other GUI does this to me. Normally, when you begin a sentence, you type a capital letter. But if the phone's UI sees a period, it automatically presses Shift for you.
This means every time you abbreviate something and use a period midsentence in an SMS, the next leter is capitalized, viz. This example.
or "it hinders my typing in emails, sms, etc. And is really annoying. this uncapitalized sentence would be another example."
Anyway how do I turn the thing off because it only wastes my time.
I find myself trying to outwit and predict this auto-cap behavior and I'm tired of it.
How do I turn it off?

Accented characters in exported images getting munged

Lightroom 2.x, OS X 10.5.6, G5, Nikon D80, Raw/NEF/DNG
I'm trying to sort out a problem I'm having that looks similar to other issues with international characters, but is a little different. My problem is specific to keywords.
I don't think this should matter, but I generally import as DNG and never save metadata to XMP. I mainly export to JPEG (to a folder that I zip up) in order to upload photos (outside of Lr) to a sharing site.
What I'm finding is that if I tag my photos (in Lr) with keywords that have accented characters (which I use a fair amount because I often travel to Francophone areas to take photos, and my IPTC data and keywords use correct French spelling) upon upload to any photosharing site I try, the keywords will be munged, duplicated and/or generally messed up. For example, I have a keyword "café". Upon export I can see this correctly in the IPTC Keyword metadata (via a third party EXIF/IPTC viewer, and also using "Get Info" in the Finder). However, as soon as I upload this JPEG to any photo sharing site the photo will end up with a series of keywords applied to it: "caf, cafe, cafã©"
Similarly, a keyword like "naïve" will end up as two keywords: "naã¯ve, nave" I get similar results with HTTP uploaders as well as uploader plugins inside Lr. And so on for è, ô &etc. In the case of Flickr, there will be one "copy" of the keyword that is correct. The others will still be present.
I've read hints that suggest that the IPTC metadata stored in the exported file by Lr might not be Unicode-clean, which causes anything that parses and normalizes select metadata (as all online sharing sites will want to do) to choke. I've heard rumours that the XMP data is properly Unicode clean, but most sharing sites ignore that data, since they are pretty much interested only in EXIF or IPTC metadata (and rightly so, I suppose.)
Is this a defect in the way Lr creates metadata in exported images? Or is is a problem with the way all these sites suck in and normalize the metadata stored in the image? Or is it a subtle interaction between the two that results in incompatibilities?
I haven't tried experimenting with creating or finding a JPEG with no keywords at all and manually inserting IPTC keywords with accents, just to see what Flickr (et al) do upon upload. I've also tried various permutations of the keyword options in the Lr export dialogue with no significant change in behaviour.
I'm interested in who else might be seeing this problem. Is it a Lr only thing, or is it Lr-on-Mac? Or something specific to the two sites I upload photos to?
I should point out that I've been seeing this behaviour since Lr 1.x.

(Jao, AdobeRGB is an experiment. I have a colour managed browser, so I wanted to see if I could tell the difference. This is a test photo from my junk pile.)
I think I see the problem. With something like ExifTool you can see that the keywords are stored in a number of places in the EXIF/IPTC header: Keywords, Subject and Hierarchical Subject. It is the Keywords section that is not Unicode clean, apparently. This is even more apparent if you show the output encoded in HTML entities:
Keywords : Franais, Test Shots, Wings of Paradise Butterfly Conservatory, butterfly, cafŽ, l'h™tel, na•ve, tests
Subject : Français, Test Shots, Wings of Paradise Butterfly Conservatory, butterfly, café, l'hôtel, naïve, tests
Hierarchical Subject : Français, Test Shots|tests, Wings of Paradise Butterfly Conservatory, butterfly, café, l'hôtel, naïve
So, it depends on what section the keywords are taken from. It appears that both Flickr and 23 will try to find the keywords in as many places as possible. This explains the many duplicates I am seeing.
So, now I just have to figure out why Subject is so wrong, and how to correct it (or leave it blank.)

Accented characters in LR for mac.

Hi all:
I'm having problems with pictures with "accented characters" in the name. I can work with these pictures, no question mark is shown, and LR can show where the actual file is located. The problem is as following: if I try to sync a folder, then LR says there are x missing files and the same x new files. If I tell LR to proceed, then the "new" pictures loose keywords, tags, edits, etc.
I have the same pictures and catalog both in windows and in mac (both version 4.4), as I'm trying to swicht, and in windows there is no problem. So it is a particular mac version problem. I tried to check the problem: if I delete these accented characters, then no new nor missing files are detected in sync, but this is not a solution (I have thousends of pictures and I want to keep the accented characters).
Is there any other solution?
This same problem has been mentioned several times, but nobody find a good solution. For example in
http://forums.adobe.com/thread/608096 and in http://lightroomkillertips.com/?p=2778
Thanks in advance.

> the problem is that I'm trying to put a "hat" over a consonant
I suspect you'll find that, the more precise and specific your question, the more greater the likelihood of getting a speedy and helpful answer.
> Looks like the software only allows the circumflex over vowels.
> Option-i does work on my computer for vowels. (Built-in
> keyboard).
Nonsense. Nothing to do with your keyboard. Btw, you still haven't told us what character you're trying to insert.
> I guess I will have to use the Equation Editor.
That's an option, but not the only one. Just for the sake of argument, let's assume it's p-hat (not the party hat, but the symbol for sample proportion).
(1) Specifically in Word, you can use fields (overstrike). Go to Insert > Field… > Equations and Formulas > Eq; then type
EQ \O (p,^)
and confirm. (Note that "EQ" will be inserted by Word automatically, you don't need to type it again.)
Once you get the hang of it, you won't need to insert it using menu & submenu commands, but by typing and applying styles.
(2) The right way is Unicode. Currently, Unicode defines >100k codepoints, so, for obvious reasons, it's neither necessary nor practical for most keyboard layouts to be able to access anything but a small subset. You can enter Unicode characters using Character Viewer (aka Special Characters), or, more efficiently, using the Unicode Hex Input keyboard layout.
If the character is already defined as such in Unicode, eg, for all (upside down A), then hold down Option and type its Unicode hex code, ie 2200 -- ∀. However, p-hat isn't defined as such, so it must be entered as a combining character sequence. The sequence is ((Latin small letter p) + (combining circumflex accent)), or (p + 0302) -- p̂.
Unfortunately, all is not sweetness and light. Although this is how it should be done, the display may disappoint. Questions 12b and 12c in the respective Unicode FAQ explain what happens and why.

Java, International language, Unicode, Chinese or accented characters

Hi, I've posted a message in the new to forum but think that this is more of an advanced problem.
Sorry for duplication.
I am having trouble getting java to output Strings that contain unicode characters out of the normal ascii set. This includes accented letters and chinese characters.
Example code:
String jintian = "??"
System.out.println(jintian) ;(The string jintian should refer to two chinese characters. I'm having trouble getting these to appear properly here, you may see ??.)
Basically if I run this code the output I get is ??. Questionmarks in place of the chinese characters.
There is either a problem here with Java or with my Shell but I don't know how to troubleshoot this.
I can tell you that my shell is able to display chinese characters, but with the ls command I have to use a flag. -v. I have tried using this -v flag with the java command but it is rejected.
One more thing, when compiling I am using the -encoding=UTF-8 flag.
I have the line ...
export LANG=en_UK.UTF-8... in my bash profile.
Any ideas, I would be really grateful.
Message was edited by:
stanton_ian
Message was edited by:
stanton_ian
In case anyone is interested in trying this themselves and doesn't know how to put in the Chinese characters here is a link to a pre-written very simple Class. http://freespace.virgin.net/i.stanton/NiHao.html .
You will need to save the file in utf8 encoding and compile it with the -encoding UTF-8 flag.

Between jdk1.2 and jdk 1.3 the default encoding of the vm changed.
You can get it by executing:
System.out.println("Default Encoding:" + System.getProperty("file.encoding"));
or
System.out.println("Default Encoding:" + (new java.io.InputStreamReader(System.in)).getEncoding());
The default encoding is used during the conversion of bytes to strings and vice verca.
Assume your default encoding is ISO8859_1. Then calling new String(byte[]) is equivalent to calling
new String(byte[], "ISO8859_1")
Now if you are converting a character from one encoding scheme to another and there is no mapping
for this character in the target scheme. Then the character will be replaced by a default character
which is (quite often) the question mark.
You can set the default encoding for a vm by passing it as a command line parameter
java -Dfile.encoding=ISO8859_1
java -Dfile.encoding=Cp1252

Greek language notes display loses accented characters

I can type in Greek in TextEdit, save the file as Unicode (UTF-16), and drag it into my iPod Notes folder.
In OS10.4 I can use accented characters in TextEdit but, when the file is loaded onto the iPod, it omits the accented characters. They aren't displayed incorrectly - they simply aren't displayed at all.
Anyone ever tried uploading Greek to an iPod? Any Greek users out there?
Martin

Yes, the accented characters appear OK on my wife's video iPod.
I suppose there's no chance that Apple will update the software on my not-very-old color iPod?
No, I thought not. Money-grabbing *****s.
I love Apple but not ALL the time.

Accented characters not encoded properly in Mail since 10.6

Messages I type that contain accented or otherwise special characters appear fine as long as I'm typing them but get re-encoded in a way that is unreadable by recipients AND by me. I.e, if I go to my Sent folder and check such messages, all accented characters have become unreadable.
I don't remember ever having that problem with 10.5
It also does not seem to be a systematic issue. I think I have it more when answering to a message or when transferring a message, as if Mail used the encoding method of the initial sender.
Anyone else has this problem?

The general approach at this time is to ask if you've checked for any problematic fonts (all languages) with Apple's Font Book (look in the Applications folder). Find and remove all duplicates also.
Start there to be sure all fonts that are in play come out with a clean bill of health.
Don't hesisate to perform wholesale deletion of old and/or little used fonts - be skeptical of anything that has come from Office 2008, including those related to an Equation Editor installation.
By all means be sure any 3rd party apps AND plug-ins are Snow Leopard compatible.
An additional measure is to clear the existing font caches:
http://www.macworld.com/article/139383/2009/03/fontcacheclear.html
That said, 10.6.2 release notes have this to say about fonts:
http://support.apple.com/kb/HT3874
Fonts fixes provided for:
• an issue with font spacing
• an issue in which some Fonts are missing
• font duplication issues
• an issue with some PostScript Type 1 fonts not working properly
Good luck in any case.

SharePoint 2010, Visual Studio 2010, Packaging a solution - The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Hi,
I have a solution that used to contain one SharePoint 2010 project. The project is named along the following lines:
<Company>.<Product>.SharePoint - let's call it Project1 for future reference. It contains a number of features which have been named according
to their purpose, some are reasonably long and the paths fairly deep. As far as I am concerned we are using sensible namespaces and these reflect our company policy of "doing things properly".
I first encountered the following error message when packaging the aforementioned SharePoint project into a wsp:
"The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."
I went through a great deal of pain in trying to rename the project, shorten feature names and namespaces etc... until I got it working. I then went about gradually
renaming everything until eventually I had what I started with, and it all worked. So I was none the wiser...not ideal, but I needed to get on and had tight delivery timelines.
Recently we wanted to add another SharePoint project so that we could move some of our core functinality out into a separate SharePoint solution - e.g. custom workflow
error logging. So we created another project in Visual Studio called:
<Company>.<Product>.SharePoint.<Subsystem> - let's call it Project2 for future reference
And this is when the error has come back and bitten me! The scenario is now as follows:
1. project1 packages and deploys successfully with long feature names and deep paths.
2. project2 does not package and has no features in it at all. The project2 name is 13 characters longer than project1
I am convinced this is a bug with Visual Studio and/or the Package MSBuild target. Why? Let me explain my findings so far:
1. By doing the following I can get project2 to package
In Visual Studio 2010 show all files of project2, delete the obj, bin, pkg, pkgobj folders.
Clean the solution
Shut down Visual Studio 2010
Open Visual Studio 2010
Rebuild the solution
Package the project2
et voila the package is generated!
This demonstrates that the package error message is in fact inaccurate and that it can create the package, it just needs a little help, since Visual Studio seems to
no longer be hanging onto something.
Clearly this is fine for a small time project, but try doing this in an environment where we use Continuous Integration, Unit Testing and automatic deployment of SharePoint
solutions on a Build Server using automated builds.
2. I have created another project3 which has a ludicrously long name, this packages fine and also has no features contained within it.
3. I have looked at the length of the path under the pkg folder for project1 and it is large in comparison to the one that is generated for project2, that is when it
does successfully package using the method outlined in 1. above. This is strange since project1 packages and project2 does not.
4. If I attempt to add project2 to my command line build using MSBuild then it fails to package and when I then open up Visual Studio and attempt to package project2
from the Visual Studio UI then it fails with the path too long error message, until I go through the steps outlined in 1. above to get it to package.
5. DebugView shows nothing useful during the build and packaging of the project.
6. The error seems to occur in
CreateSharePointProjectService target called at line 365 of
Microsoft.VisualStudio.SharePoint.targetsCurrently I am at a loss to work out why this is happening? My next task is to delete
project2 completely and recreate it and introduce it into my Visual Studio solution.
Microsoft, can you confirm whether this is a known issue and whether others have encountered this issue? Is it resolved in a hotfix?
Anybody else, can you confirm whether you have come up with a solution to this issue? When I mean a solution I mean one that does not mean that I have to rename my namespaces,
project etc... and is actually workable in a meaningful Visual Studio solution.

Hi
Yes, I thought I had fixed this my moving my solution from the usual documents to
c:\v2010\projectsOverflow\DetailedProjectTimeline
This builds ok, but when I come to package I get the lovely error:
Error 2 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\VS2010\ProjectsOverflow\DetailedProjectTimeline\VisualDetailedProjectTimelineWebPart\Features\Feature1\Feature1.feature VisualDetailedProjectTimeline
Now, the error seems to be related to
Can anyone suggest what might be causing this. Probably some path in an XML file somewhere. Here is my prime suspect!
<metaData>
<type name="VisualDetailedProjectTimelineWebPart.VisualProjectTimelineWebPart.VisualProjectTimeline, $SharePoint.Project.AssemblyFullName$" />
<importErrorMessage>$Resources:core,ImportErrorMessage;</importErrorMessage>
</metaData>
<data>
<properties>
<property name="Title" type="string">VisualProjectTimelineWebPart</property>
<property name="Description" type="string">My Visual WebPart</property>
</properties>
</data>
</webPart>
</webParts>
.... Unless I can solve this I will have to remove the project and recreate but with simple paths. Tho I will be none the wiser if I come across this again.
Daniel

How to load CSV with accented characters?

Hi,
I have a database instance with NLS_CHARACTERSET = 'AL32UTF'. I upload a csv file with APEX into WW_FLOW_FILES table and then parse it with dbms_lob.instr. The problem that I am facing is that if I save the CSV file in UTF8, then this works fine, if I save it in any other encoding then it's displaying 'funny' characters when I try to parse it and display the parsing result and the source data contains some accented characters, like, á, é, ő etc,
I am not sure if this is an APEX issue or I rather be turning to NLS forum. TIA.
Tamas
Edited by: Tamas Szecsy on Jan 30, 2011 6:34 PM

Did you every find a resolution to this issue on importing with accented characters?

I was editing vacation photos in aperture 3 all of a sudden the thumbnail disappeared and now all i have is a vertical white line and an orange flag... how do i get my photo back? thanks

i was editing vacation photos in aperture 3 all of a sudden the thumbnail disappeared and now all i have is a vertical white line and an orange flag... how do i get my photo back? thanks

     Hi Frank.
     I have just had jb Atlanta's problem while adjusting the contrast on a photo. I was creating a slideshow at the time. After a lot of reading up I was about to give up when I tried restoring the file to its original settings as you suggested. Bingo!
     However, that would only work for me, if I restored the settings while in the slideshow. All data had 'disappeared' when I attempted to open the photo in its original project folder.
     Hope this is of help. Many thanks.

Accented Characters and Diacritic folding flag

Similar Messages

Maybe you are looking for