Check for visual presence of character on page? - html

I'm in an odd situation where I need to check, via a test, that a currency symbol is being properly displayed on our web page.
We've been running into issues where sometimes the unicode alphanumeric value is showing up on the page instead of the actual currency symbol itself.
Is there a way to check for something like this? Like with some type of visual checking library, or through javascript?

The answer to this issue was to specifically copy and paste the unicode character I was looking to test against into my text editor.
So using the Protractor framework, I would find my css element, and if I have a known price of 17.99 that should be returning, my test function would return:
return expect(myPriceElement.getText()).to.eventually.equal(£17.99);
If on my webpage, £17.99 shows up, then my test will pass

Related

html page failing to display rupee currency symbol

I have a database configuration table that holds the rupee symbol &#8377.
when my page loads a java class reads this value using jdbc from the sql server database and using xslt transformation displayed in a table.
there are no issues with the $ UK pound symbol etc, but rupee will not display. In the table I see that the value &#8377 is displayed and when I view the source I see that the text has been escaped to &#8377.
If I edit the source in chrome and change &#8377 back to &#8377 it displays fine, I'm trying to work out how to prevent this escaping from occurring.
I have tried to escape the & with \&#8377however this is still encoded to\&#8377.
I have also tried directly sticking the &#8377 into the xslt sheet in line with some text like:
<h2>Some text (&#8377)</h2>
but with this it displays as 'Some text (?)'
There must be a simple solution to this one but I've not found anything so far :(

Creating custom SSRS handler for field with HTML

I have an SSRS 2008 report with a field that contains and is configured to render as HTML. Some of the text in this field may contain IMG tags, and the IMG tag is not among the tags SSRS natively supports within its HTML rendering extension.
I am trying to find a way to write a custom handler to hook into the processing of this field that will let me look at the raw HTML before the SSRS handler processes it, in the hopes of grabbing IMG tags, extracting the SRC URL and getting the raw bytes of an image to insert on the fly in a way SSRS will accept, yet retaining the HTML SSRS will render.
From what I've read and seen so far, if a field is marked to render as HTML, the SSRS processor grabs it and parses it entirely before any handler could modify it, meaning the IMG tag is (would be) discarded before I could do anything with it (or even know it was present). The only option I see is to turn off the HTML rendering entirely, thus losing the benefit of the tags SSRS can recognize.
EDIT: Per Jamie's response below, I'm beginning to think the "2nd half" of this issue may prove harder than I realized: Is it even possible to programmatically add an Image to an SSRS Report at runtime (obviously through code/custom assembly)? That is, I'd like to write some code that might look something like this (pseudocode)
'Conceptual Pseudocode I'd like to be able to write
'for dynamic addition of Image element in SSRS report
'Is this even possible?? Is there a documented Report
'object model??
Public Function AddImage(imageBytes() as Byte) as Image
Dim newImage as New Image()
newImage.SetBytes(imageBytes)
Report.Add(newImage)
return newImage
End Function
I'm hoping I'm just overlooking something simple that prevents me from grabbing the raw, unprocessed HTML, and someone else might be able to point me in the right direction on how to grab it.
EDIT: I have created and implemented this solution within the SSRS development environment and it works. WOOHOO :) It did require some hoop-jumping with creating a Single-Threaded Apartment thread to host the WebBrowser control, and to create a message pump, but it does work! **
As I was literally typing up the message to a co-worker that this issue was a non-starter, I did have a bit of an inspiration on a way to solve this problem. I know this post hasn't generated a great deal of response, but just in case someone else finds themselves in a similar problem, I'm going to share what I've implemented in a "petri dish" scenario that, provided I get all the code permission issues resolved, should allow me a decent solution to this problem.
With SSRS inability to handle an IMG tag insurmountable, I actually thought of an idea that took the HTML rendering away from SSRS entirely. To do this, I created custom code that hands off the HTML rendering to a WebBrowser control, then copies the rendered result as an image. It does the following:
Instantiates a WebBrowser control of a given width and height.
Sets the DocumentText property of that control to the HTML from TinyMCE
Waits for the DocumentText to completely render.
Creates a bitmap equal to the size of the control.
Uses the undocumented and presumably unsupported DrawToBitmap method of the WebBrowser to draw the rendered HTML to a bitmap.
Copies the Bitmap to an Image
Saves the Image as a .png file
Returns the path to the .png as the result of the function.
In SSRS, I plan to replace the erstwhile HTML text field with an external Image control that will then call the above method and render the image file. I may alter that to simply draw the image to the SSRS Image control directly, but that's a final detail I'll resolve later. I think this basic design is going to work. Its a little kludgey, but I think it will work.
I have some permissions issues to work out with the code that SSRS will allow me to call at runtime, but I'm confident I'll get those sorted out (even if I end up moving the code to a separate assembly). Once this is tested and working, I plan to mark this as the answer.
Thanks to those who offered suggestions.
I've done something similar with success: We had an HTML "Comment" field that was collected on a web form. For a particular report we wanted to truncate this field to the first 1000 characters or so, but preserve valid HTML.
So I created a C# .dll & class with a public function:
public static string TruncateHtml(string html, int characters)
{
...
}
(I used the HtmlAgilityPack for most of the HTML parsing, and to create and close off my new HTML string, while I kept track of the content length.)
Then I could call that code with the fully qualified path to the function in an SSRS expression:
=ReportHtmlHandler.HtmlTruncate.TruncateHtml(Fields!Comment.Value, 1000)
I could have added a calculated field to my dataset with this, but I was only using this value for one field, so I kept it at the field expression level.
All of this code gets called well before the HTML is processed or rendered by SSRS. I'm sure that any original IMG tag will be in the string.
This approach might work for you, possibly create a ExtractImg function which could be set as the source of an img on the report. I think some of the tricky bits for your requirement will be to handle multiple images as well as embedding the extracted img. But you might be able to do this simply with a external reference to an image. I haven't done much with external images in SSRS.
An MSDN blog entry on calling a custom dll from SSRS: http://support.microsoft.com/kb/920769

Trademark symbol is displayed as raw text

if you visit www.startwire.com you'll see in the center of the page (in the yellow box, under the video) the following:
StartWire™
in our dev and stage environments, this is not an issue, but it is in production. What could possibly be causing this?
If you look at the page source, you will see &trade; - you are double encoding the entity.
This should be simply ™.
In the HTML you have:
<h2>Sign-up now. StartWire&trade; is completely FREE.</h2>
whereas the correct would be:
<h2>Sign-up now. StartWire™ is completely FREE.</h2>
Notice the extraneous &. Look like you are double encoding something on the server.
If you check your page source it says:
&trade;
This means that probably it took ™ and transformed that into HTML. So the & becomes &. This is probably due to the use of a htmlentities() function.
Make sure you do not do this conversion twice...
A possible cause of this is that you are taking the contents from a database and that you have encoded the entries before inserting them into the database and you encode them a second time when you retrieve them from this database.
Is the content being "HTML encoded" (or whatever they call it) automatically, somewhere in the script? Because this is what appears in the HTML: &trade;.
My suggestions would be to just use the symbol in your code (™). If that doesn't work, try escaping the & of ™ using \ (so that it becomes \™).
not sure, but i have checked your site it shows like you have write like
&™
simple write ™

How to store html characters in mysql and display them correctly

Not sure if I am asking this correctly. But I am using a Jquery HTML Editor cleditor so that the users can load html text. When I insert this into my db(mysql) and want to display the outcome it takes out any html characters it had like: <p>, <span>, and so on. So when I go view it, it shows like this:
class=\"noticia_texto\">jlasdfklsfklaf
which obviously it's not readable. Help please? Should I be using anything at the time of inserting or displaying or both? Also my datatype is set to Blob.
MySQL does NOT strip html tags. If they're being removed upon insertion (or retrieval), then it's something in your code doing it, not MySQL.
Given that the quotes in your snippet are escaped, you've almost certainly got magic_quotes enabled, and/or a home-brew SQL escaping function run amok.

How can I remove or escape new line-carriage returns within an XML string in XSL?

I've got an ASP multiline textbox that saves user defined text to a database. When I retrieve the data, I serialize it into xml and then run it through an XSL transform to output my HTML.
Within my transform, I am passing the textbox defined data into a javascript function via an onclick event of an element.
The problem I'm running into...when a user enters a carriage return into the textbox and saves it to the database, a javascript error is generated on page load.
I'm using .NET's XslCompiledTransform to do the transform. There is a property on XmlDocument called PreserveWhiteSpace, default is false, that can be set to strip out white space in the XML. This solves the problem of not allowing a user to enter breaking text, however, the client wants to preserve the formatting of the text that they enter if at all possible.
From what I know, .NET XslCompiledTransform transforms carriage returns-new line into
. I believe these are the characters that are breaking the javascript.
My first thought was to strip out the carriage returns within the xsl prior to passing the string into the javascript function, but I've not been able to figure out what characters to "search" the string for.
I guess another question is what characters get stored in SQL for carriage returns from within an ASP.NET textbox control?
Looking directly at the data in the database, SQL seems to display the character as "non-displayable" characters or (2 empty boxes).
Has anyone had any experience with this type of thing?
I was able to do this in the code behind to get my desired results:
using (StringWriter sWriter = new StringWriter())
{
xTrans.Transform(xDoc, xslArgs, sWriter);
return sWriter.ToString().Replace("
", "\\r\\n");
}
One other thing that I've stumbled across...
Initially, I wanted to find a solution to this problem that did not require a "compiled" code change, ie. a way to do this within xsl aka "a short term fix".
I tried this first and was not successful...
<xsl:variable name="comment" select="normalize-space(.\Comment)" />
This essentially did nothing and I was still receiving the javascript error.
Eventually, I tried this...
<div onclick="Show('{normalize-space($comment)}'"></div>
The second actually worked in stripping out the white space, thus, the javascript error was avoided. This wasn't a complete solution for my requirements because it only solved the issue of the javascript error, however, it would effectively prevent the user from "breaking" the page.
For that reason, it could suffice as a short term solution.