I'm pulling JSON data for display on a map, but when I grab a JSON field that has HTML code (ie, <br>) the code shows in the infowindow instead of rendering as a line break.
http://www.yourmapper.com/demo/v3infowindow.htm
Any ideas on how to force rendering?
The JSON call is in the code, but here it is directly:
http://www.yourmapper.com/api/markers.php?&lat=38.23282191&lon=-85.7209389&id=152&f=json
Thanks. (Note, I posted this in the old Google Maps Group before noticing that tech questions have been moved here).
The JSON doesn't contain <br> , it contains <br> , this issue is not forced by google-maps.
You may "decode" the strings by changing this line:
yourdescription[i] = item.description;
into
yourdescription[i] = $('<div/>').html(item.description).text();
But if I may assume that you are the developer of this service you better fix this on serverside and return the expected result.
Related
When I fetch data from this endpoint http://blog.local/wp-json/wp/v2/posts?page=1 I get a JSON object.
When I add the _embed param,http://blog.local/wp-json/wp/v2/posts?page=1&_embed, I get an image, no JSON.
According to the Wordpress documentation, when you pass the _embed parameter, you are supposed to get extra usefull data included in the response - here
I just get an actual JPG image returned.
Has anyone seen this before or know what the problem could be? I have to resort to adding custom endpoint to just get extra data back.
Okay so it turns out that a plugin I'm using to create fake posts (FakePress) for testing was causing the issue. Don't know how but disabling fixes the problem.
So I have a PDF that has been created on the fly by opening a template, modifying the values for certain fields, and then saved.
Works:
If I open the file in Chrome, I have the correct values.
If I save the file to disk and open it with Adobe Reader DC (or whatever that's called), I get the correct values.
Doesn't Work:
When I open the document in IE 10, it opens in Edge, and shows "default" values for the fields.
When I save the file to disk and open it with IE, it shows "default" values.
When I open the file using "PDF reader - Document Viewer and Manager" it shows "default" values.
I'm using Windows 10, the application I'm working on is done in ASP.Net. It works the same way whether I return a FileStreamResult, FilePathResult, or File.
And I'm now pretty much certain the problem is Microsoft's products and not my code.
Any idea why Microsoft products are incapable of opening my PDFs correctly? Do they have to be flattened in some specific way or something?
Edit (more information as requested in comments):
The documents are created using PdfSharp.
They have fields that are dynamically replaced with values (i.e. [MyFieldA] is replaced with "ActualValueA").
Once the merge fields are replaced with actual values, the file is written using File.WriteAllText(fileName,fileText); where fileText is obtained through File.ReadAllText(fileTemplateName);
Image of comparison of fields that are wonky:
So I found the solution to the problem, and it appears that it might be a two-fold thing.
One piece of the puzzle I believe was the memorystream being used to create the PDF. It was declared in an inner scope, used in a PdfReader.Open call in an assignment to a var that was declared in an outer scope, and then the scope ended, while the var was still being used. I moved the memorystream declaration to the outer scope where the var declaration was so that they would be in the same scope. Also, the memorystream wasn't being closed with a memoryStream.Close() call or in a using (var memoryStream = new MemoryStream()) { } block. So I added a call to memoryStream.Close().
The other piece is that the PDF template form fields had some default display values. It appears that Microsoft stuff (Edge, PDF Viewer) may not be able to get the inserted values, and is instead reading the default display values of the fields and displaying those. Once all of the default display values were removed, Edge began opening the PDF and displaying values correctly.
Since these two pieces were done in tandem, I can't say for certain that they both play an equal role in this, but these are the only two changes that were done to get values to start displaying correctly. My gut feeling is that the problem lies with the default display values and Edge.
I've been given the task of creating an ICAL feed of conference calls for members of our organization. I created a handler in ASP.NET that loops through our database, gets the call data from the database, and creates output that appears valid to me based on what I've read of the ICAL format, and the examples I've seen/disassembled.
Outlook 2007 reads the resulting output and displays the calendar, no problem (screenshot here shows how it renders).
30 Boxes also has no problem with it. (see test here).
But when I try to load the same output into Google Calendar, I get the message "We could not parse the calendar at the url requested":
What's wrong with my output that's causing Google to reject it? You can see the temporary data I'm testing with at this URL: http://www.joshuacarmody.com/temp/icaltest.ics. This is a snapshot of the output from my .ASHX file, unaltered except the phone numbers and passcodes have been sanitized.
Edit with additional Info:
I just tried the following
Created a copy of my test file called "icaltest-1googevent.ics"
Deleted all the VEVENT data from the file
Exported one of my Google calendars to ICS
Copied one VEVENT from Google's exported data into my test file
Attempted to subcribe to icaltest-1googevent.ics in Google Calendar.
I still got an error message. So I'm guessing the issue isn't with my VEVENT data, but with something else about the file. Maybe there's something wrong with my VCALENDAR definition?
the severinghaus ics validator seems to think there is something funny ( a ? ) before the BEGIN CALENDAR
http://severinghaus.org/projects/icv/?url=http%3A%2F%2Fwww.joshuacarmody.com%2Ftemp%2Ficaltest.ics
In my testing google was a lot fussier/rigourous/pedantic - once you get it working with the validator and google it should work in most places.
After lots of trial-and-error, and comparing my output with Google's, I got it working. There were a few problems with my ICS file:
Unescaped characters (I didn't know I had to escape commas!)
Inconsistent line return characters. They didn't show up in my text editor, but I had to use .NET's String.remove() to remove "\r" from my output to get Google to recognize it
The file was missing VCALENDAR:END. Apparently Outlook doesn't much care. Google does.
I had not one, but three funny characters before the BEGIN:VCALENDAR, decimal codes 239, 187, 191.
I found them thanks to the severinghaus.org link above, thanks!
It turns out they're a prefix called BOM in UTF-8, you can read up on it here: http://en.wikipedia.org/wiki/UTF-8#Byte_order_mark
Google doesn't handle this, but after stripping these three characters from the file and uploading to the server, I was able to susbribe to that calendar in Google Calendar (from URL).
I hope this helps someone passing by this page in the future...
I had similar problem until I realised that opening the generated .ics file in Notepad++ wasn't in UTF-8. I was using a method to convert my string to a byte array, but wasn't using an encoder for this, so no matter what content headers I used, the file would never be generated using UTF-8. This simple fix resolved the UTF-8 generation and Google is now happy with my feed:
var utf8 = Encoding.UTF8;
byte[] utfBytes = utf8.GetBytes(myString);
myString= utf8.GetString(utfBytes, 0, utfBytes.Length);
I want to make an XML document from an HTML one so I can use the XML parsing tools. My problem is that my HTML is not guaranteed to be XHTML nor valid. How can I bypass the exceptions? In this string <p> is not terminated, nor is <br> nor <meta>.
var poorHtml:String = "<html><meta content=\"stuff\" name=\"description\"><p>Hello<br></html>";
var html:XML = new XML(poorHtml);
TypeError: Error #1085: The element type "meta" must be terminated by the matching end-tag "</meta>".
I did some searching and couldn't come up with anything except this doesn't really seem possible, the major issue is how should it correct when the format is not valid.
In the case of browsers, every browser does this based upon it's own rules of what should happen in the case that the closing tag isn't found (put it in wherever it would cause the code to produce a valid XML and subsequently DOM tree, or self terminate the tag, or remove the tag, or for the case that a closing tag was found with no opening how should this be handled, what about unclosed attributes etc.).
Unfortunately I don't know of anything in the specification that explains what should be done in this case, with XHTML just like how flex treats it these are fatal errors and result in no functionality rather than how HTML4 treated it with the quirky and transitional DTD options.
To avoid the error or give better error messaging you can use this:
var poorHtml:String = "<html><meta content=\"stuff\" name=\"description\"><p>Hello<br></html>";
try
{
var html:XML = new XML(poorHtml);
}
catch(e:TypeError)
{
trace("error caught")
}
but it's likely you'll be best off using some sort of server side script to validate the XML or correct the XML before passing it over to the client.
There is probably an implementation of HTML Tidy in just about any language you might happen to be working with. This looks promising for your sitation: http://code.google.com/p/as3htmltidylib/
If you don't want to drag in a whole library (I wouldn't), you could just write your own XML parser that handles errors in whatever way suits you (I'd suggest auto-closing tags until the document makes sense again, ignoring end tags with no start tags, maybe un-closing certain special tags such as "body" and "html"). This has the added advantage that you can optimize it for whatever jobs you need it for, i.e. by storing a list of all elements with the attribute "href" as you come to them.
You could try to pass your HTML through HTML Tidy on the server before loading it. I believe that HTML Tidy does a good job at cleaning up broken HTML.
I'm breaking my head over this for a while now and I have no clue what I do wrong.
The scenario is as followed, I'm using swfupload to upload files with a progressbar
via a webservice. the webservice needs to return the name of the generated thumbnail.
This all goes well and though i prefer to get the returned data in json (might change it later in the swfupload js files) the default xml data is fine too.
So when an upload completes the webservice returns the following xml as expected (note I removed the namespace in webservice):
<?xml version="1.0" encoding="utf-8"?>
<string>myfile.jpg</string>
Now I want to parse this result with jquery and thought the following would do it:
var xml = response;
alert($(xml).find("string").text());
But I cannot get the string value. I've tried lots of combinations (.html(), .innerhtml(), response.find("string").text() but nothing seems to work. This is my first time trying to parse xml via jquery so maybe I'm doing something fundemantally wrong. The 'response' is populated with the xml.
I hope someone can help me with this.
Thanks for your time.
Kind regards,
Mark
I think $(xml) is looking for a dom object with a selector that matches the string value of XML, so I guess it's coming back null or empty?
The First Plugin mentioned below xmldom looks pretty good, but if your returned XML really is as simply as your example above, a bit of string parsing might be quicker, something like:
var start = xml.indexOf('<string>') + 8;
var end = xml.indexOf('</string>');
var resultstring = xml.substring(start, end);
From this answer to this question: How to query an XML string via DOM in jQuery
Quote:
There are a 2 ways to approach this.
Convert the XML string to DOM, parse it using this plugin or follow this tutorial
Convert the XML to JSON using this plugin.
jQuery cannot parse XML. If you pass a string full of XML content into the $ function it will typically try to parse it as HTML instead using standard innerHTML. If you really need to parse a string full of XML you will need browser-specific and not-globally-supported methods like new DOMParser and the XMLDOM ActiveXObject, or a plugin that wraps them.
But you almost never need to do this, since an XMLHttpRequest should return a fully-parsed XML DOM in the responseXML property. If your web service is correctly setting a Content-Type response header to tell the browser that what's coming back is XML, then the data argument to your callback function should be an XML Document object and not a string. In that case you should be able to use your example with find() and text() without problems.
If the server-side does not return an XML Content-Type header and you're unable to fix that, you can pass the option type: 'xml' in the ajax settings as an override.