When displaying a PDF with standard (US letter) size pages, the PDF appears to be 'zoomed out' in Chrome. In Firefox, the PDF shows at a better zoom level.
Here is an example:
http://www.pdf995.com/samples/pdf.pdf
When viewed in Chrome on a 4k monitor, it is zoomed out so far that you can see 1.5 pages. While in Firefox you can see roughly half of the first page which in our case is much more desirable.
Is there any way that we can display this PDF at a standard zoom. For example, setting some headers, etc.
I'm currently using PHP to display the PDF, by setting the following headers and then echoing out the file.
Content-type: application/pdf
Content-Disposition: inline; filename=filename.pdf
Any ideas or suggestions would be great!!
From the description above
Chrome was and still does generally use "standard" 100% zoom.
Whilst FireFox was using Fit Width ("roughly half of the first page").
Many pdf extenders but not all will use the Adobe Acrobat URL trailing fragment so for the example in question try
http://www.pdf995.com/samples/pdf.pdf#zoom=200
however that can be fickle and require a second refresh of same URL.
Better (for more consistency) with the questions description of Firefox at the time use.
http://www.pdf995.com/samples/pdf.pdf#view=FitH
Which for me, with my current window in Chromium Brave / Edge will be 136% on this occasion, but some other 100%hv on a different window setting or screen.
Note the above can be over-ridden as much HTML can by the clients setting so assuming they allow a PDF to run with its own control, it works but if they pre-set remember last PDF view setting it may not.
Related
I'm currently trying to display PNGs with react-three-fiber but when I set a texture with a transparent background it doesn't show.
I've tried many things but noticed that if I take the base64 of the image and load it into a img html element, it doesn't display either, otherwise, if I put it as an href for an a element, I can download it with no issue.
Here is a live exemple where you can download the file but not load it into an img:
https://codesandbox.io/s/kind-elion-tznyx?file=/index.html
You may open the sample in a separated tab as codesandbox is preventing file download from the reduced window.
If anyone ever experienced this, maybe something in the base64 is wrong.
Testing this same demo in Safari, it will work correctly. In Firefox and Chrome it does not. Data URIs are best used for small images — they add a ~30% size penalty to the data they store, and a significant amount of extra processing is required to display them. Browsers including Chrome impose limits on the supported length of Data URIs for this reason, see https://stackoverflow.com/a/41755526/1314762 for details on those limits.
I understand that adding <meta name="viewport" content="..."> determines the layout on mobile browsers for HTML documents - but is there something (e.g. HTTP header) that tells the browser how to display documents such as plain text files?
Case in point, Gmail's robots.txt looks tiny, like a desktop website without a viewport meta tag:
On the other hand, StackOverflow's robots.txt is displayed in a more mobile-friendly way on the same browser:
Is this standardized anywhere? Does Chrome have some undocumented heuristic to decide this?
No, there is nothing that tells the browser how to display documents such as plain text files.
For some reason Chrome (mobile) zooms only .txt files with more than 302 characters.
This seems to be true for other webkit browsers too.
Gmail's robots.txt is 128 characters long and Chrome doesn't zoom it.
Here are two almost identical files, in the same folder; the only difference is the number of characters stored.
301 characters long .txt file:
http://tonttest.altervista.org/301byte.txt
302 characters long .txt file:
http://tonttest.altervista.org/302byte.txt
Not a complete answer, but I don't think it should be a comment either.
Some testing indicate that it's not related to HTTP headers but related to a zoom formula which uses character count and viewport width. Formula could probably be derived from here. But I'm not up to that task.
A few findings about this "formula":
Shows visible effect only when viewport width <= 980
Starts working when character count < 302
Firefox doesn't care about it.
I'm guessing this is actually a standard and Firefox didn't implement it because it's not that important. But I could be wrong, and it could be a non-standard Chrome thing.
also, in html from personal experience i know that when programming or coding a website, you have to put more effort into actually coding it to make it fit nicely to a mobile screen and/or a computer screen/monitor. a quick google search would help you with that too.
in your case, it's possible that google didn't bother to put forth the effort into styling that page so that its more easily viewable on mobile devices, and figured that people aren't typically going to be going to that text file on the gmail website. and they may have also figured that if someone did want to or need to view it, they'd be doing something such as, but not limited to programming or coding.
and stack overflow decided to because its a website revolving around coding and programming.
hope this helps!
On high dpi screens, pages with initial-scale=1 will effectively be zoomed by browsers. Their text will be smooth and crisp, but their bitmap images will probably not take advantage of the full screen resolution.
The company I work for stores some of their product images in Google cloud storage, and I've been able to fetch the images however when putting the img tags onto a page, they appear to be in the wrong orientation i.e landscape instead of portrait (no issues with images taken in landscape mode).
When viewing the image in a new tab however they appear correctly!
Is there a reason why this may be? Suggestions are appreciated.
I have tried putting the img on a blank page without an anchor wrapping it to see if that made a difference and it did not.
I'm guessing the OP is having problems due to EXIF data. If the original images contain EXIF data indicating that they should be rotated, special measures must be taken to get that data interpreted by a web browser when displaying a page. It is discussed here:
Is there a way to tell browsers to honor the jpeg exif orientation?
If the the solutions provided for exif orientation are not acceptable, the OP will have to preprocess the images to rotate them to proper orientation and save them that way on the serverside. Then the correctly rotated images can be delivered on web page.
I'm working on a page that has the following markup:
<img
alt=""
src="/banner_home.300x200.jpg"
srcset="/banner_home.300x200.jpg 320w,
/banner_home.600x400.jpg 480w,
/banner_home.728x242.jpg 768w,
/banner_home.920x306.jpg 960w,
/banner_home.1234x400.jpg 1280w">
and it seems that in the latest Chrome & Opera, they ignore whatever the screen size is and just output whichever file is listed last (so the 1234x400.jpg in my case).
Using Picturefill, Firefox and Safari both show the correct image on smaller screens.
During my testing today I launched Opera which I hadn't opened in a while. When it first launched it was at v25 and it would show the correct image at smaller screen sizes.
Then I noticed that an update had been downloaded, so I ran it, got updated to v27, and then Opera was displaying the same problem as latest Chrome.
So it seems that something has changed in Blink recently.
Can anyone else confirm this or am I just doing it wrong?
Codepen to illustrate what I mean.
You're holding testing it wrong :D
A change that went into Chrome 40 means that when a high density resource is available in the cache (e.g. the largest possible image in your example), this is the resource that would get picked, since there's no point in re-downloading a different, lower-resolution one.
If you really want to test which resource gets download in smaller devices (not that you should rely on which resource gets picked, because srcset is not about that), you can either test on an actual device, or alternatively, open an incognito session, resize the browser (or emulate a device) and only then load the test page.
I've also created a slightly clearer test case out of yours, when you can see which image was loaded.
Also: from your example it looks like you are using images with different proportions inside srcset. That's not something you should use srcset for, but rather use <picture>, that provides guaranties regarding which resource is loaded, so your layout won't break because the wrong image loaded.
When you're using srcset there is no "wrong" image. The browser is free to pick whichever one it sees fit (because its in the cache, connectivity is low, user preferences say so, etc).
If you paste this into your console, you'll see the image source that is being rendered in your browser.
console.log(jQuery('.your-image-class img').prop('currentSrc'));
On this page, the images look fine on desktop but are white/not found on mobile devices. I have no idea why this is happening. I'm just calling an img tag but it says its not found on mobile even though it is there
I have checked your files, #MrVimes is correct your should finish your html which will help validate better on slower devices.
However the problem is purely down to size of the image. Chrome Dev tools shows me that they are massive in size, Enable emulator and select iPhone 5 and see what happens. It is just taking a long time to download.
Try using Picturefil.js to serve smaller images or make them smaller in your software application.
This was the picture I got from Google Dev Tools (which is free and amazing):
Also I noticed that your need to change the way the images are handled in CSS, if you open dev tools:
Position:center
Is not valid, maybe set it to relative or static depending on how you want your page structure to look.
I also saw you may want to update your header with this css:
z-index: 99999;
This will make your header appear on top, as the z-index changes the layers of the html elements (much like the fillings in a sandwhich)
sorry my friend but this is false COMPRESSSING THE IMAGES TO 50KB the big images won't appear because your cache browser is full you have to empty your history/cookies/cache of the browser
IOS DEVICE SUPPORT 32 MEGAPIXEL SIZE OF IMAGE IN SAFARI
take a look here for maximum image size and resolution support Apple IOS developper
to delete your cache just go to "Setting=>Safari=>Cleare cache=>clear cache" and that's it
Note: Check the avaible space on your IOS DEVICE should be greater then 50MB
You have to Enjoy the technologie by let the images greater then 1.5mb and works in both of computers/devices