Does anyone know what the Maximum URL length is in Silverlight (version 4 if it matters)? I know it is 2048 and basically infinite for Firefox (the two environments I have tested in), but Image requests fail for long Uri's. Anyone know the magic number (is it 256 the max filepath length?) It is considerably shorter than the 2048 for IE...
According to the .NET framework library for Silverlight The Uri scheme can be 1024 while a complete Uri can be up to 65519 characters long. This is valid for both v3 and v4.
Hope this gives you some guidance.
EDIT
Okay, well after long testing, I managed to track down the limit for an image URL.
The scheme refers to the http part.
The whole URI cannot be longer than 2047 after which it seems to not load the image anymore. However, I could not find any official reasoning behind it.
The fact that you are getting AG_E_NETWORK_ERROR exceptions does not have anything to do with the length of the URI.
You can check however, if there are any illegal characters in your URI:
You can find the reserved characters in RFC2369 and see their web counterparts at w3schools
I also found that if the link is placed in the XAML, you have to replace the '&' sign with its '%26' counterpart.
Related
I am building an Angular test preparation app (with Laravel 5.1 API). One of the requirements is to allow the user to print a certificate of achievement.
The client wants the person's name and credentials interpolated into the document (e.g., highlighted below). Here is a snapshot of the PDF template they sent:
The way I'm handling PDF viewing is simply by storing the file on S3 and giving them a link to that file.
Interpolating information into a PDF doc doesn't seem trivial and I haven't found much information on programmatically allowing this, but there are tools like DocHub, that allow you do edit while viewing the PDF.
I'm interested in learning:
is doing this programmatically trivial?
are there 3rd party tools I'm unaware of?
would I even be able to send this information along to the S3 link to interpolate in the first place?
Using PDF as a format for editing is usually a bad choice. If you have a form with fixed fields, then it's easy. Create a PDF template with an interactive form. In this form, based on AcroForm technology, you'll define fields with fixed coordinates, and a fixed size. You can then add content to these fields.
One major disadvantage with this approach is the lack of flexibility. Did you notice that I used the word "fixed" three times in the previous paragraph? If text doesn't fit the predefined field, you're out of luck. If the field is overdimensioned, you'll end up with plenty of white space. This approach is great if you can predict what the data will be like. A typical use case is a ticket or a voucher. For instance: the empty form is a really nice page, with only a couple of fields where an automated system can put a name, a date, a time, and a seat number.
This isn't the best approach for the example you show in your screen shot. The position of every line of text, every word, every character is known in advance. If you want to replace a short word with a long word (or vice-versa), then all those positions (of each line, of the complete page, possibly of the complete document) need to be recalculated. That's madness. Only people with very poor design skills come up with such an idea.
A better idea, is to store the template as HTML. See for instance chapter 5 of iText's pdfHTML tutorial, where we have this snippet of HTML:
<html>
<head>
<title>Invitation to SXSW 2018</title>
</head>
<body>
<u><b>Re: Invitation</b></u>
<br>
<p>Dear <name>SXSW visitor</name>,
we hope you had a great SXSW film festival experience last year.
And we would like to invite you to the next edition of SXSW Film
that takes place from March 9 until March 17, 2018.</p>
<p>Sincerely,<br>
The SXSW crew<br>
<date>August 4, 2017</date></p>
</body>
</html>
Actually, it's not really HTML, because the <name> tag and the <date> tag don't exist in HTML. All HTML processors (browsers as well as pdfHTML) ignore those tags and treat their content as if the tag was a <span>:
It doesn't make much sense to have such tags in the context of pure HTML, but it does make a lot of sense in the case of pdfHTML. With pdfHTMLL, you can configure custom tags, and have a result that looks like the PDFs shown below:
Look at the document for "John Doe" and compare it with the document for "Bruno Lowagie". The name "John Doe" is much shorter than my name, hence more words fit on that first line. The text flows nicely (we could also have chosen to justify the text on both sides). This "flow" is impossible to achieve with your approach, because you will never get a PDF template to reflow nicely.
OK, I get it, you probably say, but what about the practical aspects? You talk about a Java / .Net library, but I am working with Laravel and Angular.js. First, let me tell you that I don't think you'll find any good PDF tools for Laravel or Angular.js, because of the nature of PDF and those development environments (in my opinion, those technologies don't play well together). Regardless of my opinion, this shouldn't be much of a problem for you because you work in an Amazon environment. AWS supports Java, and the Java code needed to get pdfHTML working is minimal. Most of the code samples I wrote for the pdfHTML tutorial are shorter than 15 lines. So why not try Java and pdfHTML?
If you're already using Amazon services, why not use an amazon lambda function, in combination with iText7 (java), to generate the pdf on demand?
That way, you are guaranteed that the pdf is correct, and has nice layout every time.
Generating the pdf can either be done by:
converting HTML,
programmatically creating your entire document,
filling and flattening an XFA form.
I think for your use-case, either option 1 or 2 are the most sustainable.
We received a complaint that some visitors to our website are dialing the wrong number to get in contact with us.
Our website has a hyperlink in the following form in the footer:
Call us at 12345678
Note that the "+47" (international code) is NOT displayed visually, it is only included in the hyperlink. But now it turns out a limited number of people (circa one a day) is actually calling a private local number at 47123456. Not many considering the size of our business, but still a major nuisance for the family receiving these calls.
The people calling say they just pressed the link to dial.
Has anybody else had these problems? Is anybody aware of mobile phones that do not properly support the tel hyperlink? Any suggestions for a solution? (Apart from changing our or their phone number, of course.)
There are different ways smart phones pick a telephone number.
some are reading the text of your website - some use the tag
on my first try: I would add the +47 to the displayed telephone number
on my second try (or both together): I would replace +47 with 0047 (its norway - or?)
and before posting i got a third idea: which encoding has the webserver and which encoding has the html / PHP page in sourcecode? Both UTF-8 or something else?
Maybe your server is sending it in a different way than the website is created and somehow some smartphones can't handle it correctly.
The problem here is pretty simple: this is the URL-Encoding.
The + char is an reserved character within the URL and represents an space.
To get an actual + sign replace it with the URL encoded version: %2B
See Links for details:
Wikipedia
W3Scools
I'm building a small webapplication which should store urls as input of a form. Sometimes urls can have attributes, parameters etc. like https:/www.stackoverflow.com/search?q=This+could+be+a+very+long+string. But some 'experts' could make use out of the missing validator, which checks the length of the string. Otherwise a limitation would may let occur an error if the url is to long.
I'm using for now SQLite3, but the solution should work database-independent.
So I am having consistency issues with a certain set of unicode characeters. The characters within the buttons under the reply section, and at various parts of the page show up as squares: http://bit.ly/zlhgEI
When I copy them into google i can navigate to a wikipedia page describing that character. So it seems like it is a rendering issue. Or perhaps that platform is just missing characters? I don't know.
Where it works: Firefox (I think on any platform), Chrome on windows7 and ubuntu maybe osX
Where it is broken: Chrome on XP, iphone4 and droid incredible
Does anyone know a way to ensure this character set will get added. I already tried adding to utf-8 meta tag, which seems to do nothing. What can I do?
Thanks!
This is primarily a font problem. The buttons contain Syriac letters, which are not present in most fonts. The CSS setting is font-family: Helvetica,Arial,sans-serif, but Helvetica and Arial do not contain Syriac letters, so browsers will first try the font to which they map the generic name sans-serif. It most probably does not contain Syriac letters either, so browsers will either give up and e.g. show a square or (more properly) scan through the fonts available on the system. So indirectly this is a browser issue too.
The odds are that the vast majority of users will not see the Syriac letters unless you use an embedded font for them. For suitable fonts, you could check
http://www.wazu.jp/gallery/Fonts_Syriac.html
where many download links don’t work, but try
http://www.bethmardutho.org/index.php/resources/fonts.html
You could also write a CSS rule with fonts that contain Syriac letters, e.g.
font-family: Estrangelo Edessa, TITUS Cyberbit Basic, Sun-ExtA, Code2000, unifont. But most people don’t have any of them in their computers, so consider adding the downloadable font of your choice into the list, once you’ve selected and installed one.
The character encoding is not a problem. The data is UTF-8 encoded and declared as UTF-8 in HTTP-headers, so meta tags don’t affect encoding issues (as long as the page is viewed online).
The buttons look really odd (each occupying the full width of the window) on IE 9, but this seems to be unrelated to the problem at hand, and it’s a Quirks Mode issue and can be fixed by adding <!doctype html> at the start.
This could be an example of mojibake. There's probably not a ton you can do about it -- I believe it depends on the fonts available and the range of encodings they support.
I am looking to use data uri base 64 strings in my asp.net c# web application. I know only some browsers support this, so at runtime I will need to check if the current browser supports base 64 strings.
From the users request object, I can access the HttpBrowserCapabilitiesWrapper object which describes the current browser.
Is it possible to find based on this if the browser supports data uri's? Or if not based on this object, is there any way at runtime I can check if the browser supports data uri's?
You cannot determine whether the browser supports data uri or not on the server side. HttpBrowserCapabilitiesWrapper does not provide that information. According to my knowledge except IE(< 7 version) all the browsers support base 64 encoded strings. You can basically use trial and error approach to handle such situations if you dont want to code browser specific.
<img src="data:image/gif;base64,..." onabort="function(){this.src='urlWhichWillRenderBinaryData'}" onerror="function(){this.src='urlWhichWillRenderBinaryData'}" />
onabort/onerror event will be fired if the image is not rendered properly.
have a look to this link, to put it simple it tries to load in image using data uri, if size is wrong it means that your browser doesn't support data uri and then you have to roll back to a backup solution.
Hope this helps
ShankarSangoli's answer may not work as written. IE 6, for instance, will attempt to load the src and fire the onerror event before your onerror function is assigned.
For this to work, you should assign onerror prior to setting the src value (can't be done entirely in markup):
Markup:
<img data-uri="{data-uri-value}" data-fallback-url="{fallback-url}" class="imageuri" />
jQuery:
$('.imageuri').each(function () {
this.onabort = this.onerror = function () {
$(this).attr('src', $(this).attr('data-fallback-url'));
};
$(this).attr('src', $(this).attr('data-uri'));
});
Tested in IE 6, IE 9 and Chrome 16.