I am using the most excellent PHP library ePub to on-the-fly create digital books from HTML stored in my database.
As these are part of a collection, I am including a cover image for every book. Everything works fine in the code but depending upon the device/software interpreting the ePub, the image may get cut off. I have seen 600x800 pixels as a recommended size, but it still cuts it off (for example in Aldiko in Android). Is there a standard size that is recommended in the documentation?
Honestly, I would love a good and readable recommendation for documentation of the ePub format.
So, it seems that Aldiko has the problem, and not the other e-Readers I have tested (Calibre, Overdrive).
After trying various ratios, I found that Aldiko only respects the height:100% style I have called out in the height direction. It doesn't scale the image, only sets the height at 100% of the screen width. I am going to have to go with this being a bug in Aldiko, and keep the recommended 600x800 ratio for maximum resolution.
Another interesting thing I discovered as well; the Aldiko reader didn't recover as well from non-standard HTML. On one of the database entries, a <style> tag inside the <body> disappeared, but the style text did not. This is not the same for the other e-Readers.
The best general advice I found on the internet is Preparing Images for Ebooks Project (PIFEP).
Related
I'm optimizing the speed of a WordPress website (on mobile only for the moment), with success except for CLS. The CLS became extremely high after optimizing CSS delivery (with WP-Rocket), but I don't see any layout shifts, even when I use Dev Tools (performance test). (on mobile)
Here’s the example : https://trustmyscience.com/israel-a-pratiquement-eradique-la-covid-19/
Results here, with CSS delivery optimization
So it seems to be an invisible layout shift, that Lighthouse perceive as a real layout shift. Lighthouse shows me the problem comes from <div class="entry-content body-color clearfix link-color-wrap progresson">. So, it seems to be related to some "wrapping" of the all article content, that maybe shifts into the background (without being visible), because of some CSS rules maybe ?
Here, the element with the highest layout shift
The element with the highest layout shift (detail)
When I deactivate CSS delivery optimization, CLS go back to almost 0 (but LCP is too high).
Results WITHOUT CSS delivery optimization
I need this CSS delivery optimisation because of LCP importance, but I also now need to solve this issue because of CLS introduction in Core Web Vitals, and need to find what Lighthouse is detecting as a LS. Also, maybe, Lighthouse needs a correction for that ? As it isn't a visible layout shift...
Do you have any idea on how to solve this ? Or do you think I need to reach LS developers to show them this ?
Thank you in advance for your help.
Regards,
The CLS is visible, it's the font.
Don't you notice that when you visit the page, the text gets resized? That's a common cause of CLS.
How to solve?
Serve your fonts locally. Do not use any plug-in like OMGF. Do it manually.
Download the fonts. Choose 2 fonts, one for body, another for headings. You won't need bold, italic, or bold+italic fonts. These will be applied by user's browser.
Convert to woff2 (only woff2 is enough, didn't face any issues)
Upload it to your server
Add font face CSS to declare the fonts
Apply the fonts using CSS elements
Disable Google fonts if you're using any WP theme or builder
Preload the fonts
This will solve the CLS problem, will also reduce the Total Blocking Time.
You might gain a bit in performance by self-hosting the fonts instead of making a call to the Google Fonts API, but fonts are not the main issue here. Javascript is.
There is a lot of Javascript on this website, so the main thread is busy downloading it, parsing it and executing it.
I ran both Lighthouse (with Clear Storage and Simulated throttling enabled) and WebPageTest with a Moto 4G profile.
As you can see from Chrome DevTools and WebPageTest, roughly 56% of the processing time spent on the main thread is due to scripting. Do you really need all of that Javascript?
Here is what I noticed in the Chrome DevTools Performance panel:
There seems to be 5 front-end.js scripts (and 1 min-front.js). Are they duplicates?
Do you need animations with gsap and ScrollTrigger?
Aren't lazyload.min.js and areimagesloaded.js doing the same thing? (I might be wrong)
Are you importing the entire lodash library? If so, try importing just the functions you are actually using.
Do you really need a polyfill for Intersection Observer? I think that all modern browsers support it natively nowadays.
CLS is basically the sum of all unexpected layout shifts that occur on a page. As you can see from the dashed orange line in the chart below, the 4 .woff2 font files contribute to the CLS: the first layout shift occurs as soon as the fonts are fetched.
But as I said, I would focus on removing all unnecessary Javascript. In particular, I would examine third-party JS like the one coming from choices.consentframework.com, which takes 1730ms to load and represents 25% of the content size (see below).
After JavaScript, focus on the images.
The Performance panel in Chrome DevTools shows a lot of requests for images. Are you fetching only the images that are in the viewport, or all the images that are on the page?
Most of these images are WebP and seem already optimized, but there are a few GIFs, which are really bad for performance. It seems that these GIFs are served by https://www.viously.com/ (I guess it's an Ad Server, it's the first time I see it).
Last but not least, double-check that all of your <img> and <video> have size and width attributes set. Images and videos are replaced elements with intrinsic dimensions, and forgetting to set sizes for images in your HTML is a common cause of layout shifts.
See also this article by Addy Osmani for a few more tips on how to optimize CLS.
I have a website that is using Angular material. I like elements and everything except default font sizes and elements are huge. To see website in acceptable scale me or my users have to zoom out at least 75% on the desktop and majority of my users are desktop users. Is there a way to specify in angular material to use smaller fonts, elements, etc?
in your main css file
add following
html {
font-size: 62.5% // adjust the size with percentage here.
}
and i recommend using em and rem for font-sizing
let me know if it didn't worked, i might provide another solution
Before you attempt anything, make sure you are using the correct fonts and font sizes by following the typography guide.
Font sizes can be adjusted by customizing the typography. Changing the size of elements is technically possible, but to do it you would need to override the styles for every Angular Material component - so it is highly impractical.
Also, component sizes as well as font sizes are determined by the Material Design specifications, so changing things means you are no longer properly following the specification, and IMO you would end up with a bad looking web site (at least bad looking in terms of following Material Design).
Often I will want printed versions of docs so I can read them in comfort, without straining my eyes reading text on a screen and sitting in an uncomfortable office chair for long periods of time.
Sometimes docs, like the Bootstrap docs, are important to be printed with the formatting / page css included (duh - it's Bootstrap), since that's what the docs are there for... to show you how to style things.
How do I get a printed copy of the bootstrap docs, for instance, the css page, while preserving the layout and styling?
I have found a somewhat inglorious workaround - when printing, choose A3 or Tabloid paper size with Landscape orientation. Also, you may need to print the entire page instead of just a region of text to get the formatting just right.
These paper sizes more closely resemble a monitor size / resolution, so the page will print with more of the CSS preserved as shown on a larger computer screen.
I would have answered this on the previously-asked question here, but it was Closed due to being "off-topic".
I am using MYSQL workbench to generate an EER diagram, and to the best of my knowledge, one can not control the dimensions of the canvas, only the size in number of pages. This has the result that you get a huge amount of white space around your diagram, making it nearly unusable. Why anyone would design it this way is beyond me. There are a lot of questions which ask how to crop a pdf, but they are either more complicated (ie. crop to a certain dimension, or crop and output to different format and ratio) or they do not preserve the image quality, or they just plain do not work. My question therefore is this:
How does one create or convert an EER diagram using MySQL Workbench such that there are no white borders AND the image quality is preserved?
Note I asked the question here as it pertains to databasing, but apologies if it is in the wrong place.
Looks like what you are after is a way to limit the output of an image export to a relatively small area, so that it fits nicely in another document. Several options are possible:
1) Export as png and simply cut off the unwanted parts. Depending on the further usage this might be good enough.
2) Export as SVG and use any of the SVG editors to limit the image size to the wanted area only. Then convert it to the format you need in your target document.
3) Set a paper size in the model that encompasses the content as close as possible. E.g. the statement paper type is quite small. Then rearrange your objects. Resize them if you need larger ones. By setting a larger font (via Preferences) you should be able to make the entire appearence larger. Then export as PDF.
In CSS Sprites you will often find padding between each image. I believe the idea is so that if the page is resized then one image won't bleed into another.
I think this depends on the different types of browser zoom (best explained by Jeff).
However, I haven't been able to see this behaviour in my tests. Is this only a problem with older browsers? (I havent been able to test with IE6 at the current time so I'm counting that as 'old').
Should I still worry about leaving space? Its kind of a pain.
For instance :
A CSS Sprite I found for AOL has
padding between each image : VIEW
but The Daily Show decided not to
bother : VIEW
It shouldn't need to be padded, but when zoomed, especially in IE8 (betas more than the RC), there is image bleeding if there is no padding.
Best example is to go to Google.com -> Search, and zoom... you'll start to see "underlines" at the bottom right of the image as the zooming rounds up/down.
In theory, a 1px padding on all sides of a sprite should be fine.
Here's the sprite from Google (images)...
But when zoomed, the +,-,x icons bleed into the main Google logo.
Basically the answer is yes. Two years to the day after I asked this question will see the release of IE9. IE9 has this problem just as much - if not more than any other browser...
It's pretty infuriating because it's such a simple thing to fix.
With iPads increasing in marketshare - its's pretty essential to at least have a half decent experience with zooming un-uniform amounts.
I am going to have to put a single pixel border around every image to match the background color of the adjacent element (potentially different on each side). Fortunately I auto-generate all my csssprites based on an .xml file - so I can do this programatically without too much hastle. It's still a huge pain though...
Simon - My experience is that this is certainly still a problem.
In response to your second question, why not use transparent padding? (Perhaps you are still supporting ie6 and this is non-trivial, in which case, I'm really sorry).
Speaking of the older browsers (those using text zoom), you don't always need padding.
The main difference between your two examples is that the Daily Show sprite already includes the menu item's text in the image itself.
When using text zoom, the AOL menu items could stretch out vertically due to the larger font size, and the menu text might even wrap to two lines. To accommodate for such eventualities, those icons need a little padding to ensure they don't bleed. Typically, you'd just try to make sure it doesn't bleed on any of IE6's five text sizes.
Since The Daily Show's menu doesn't contain any (visible) HTML text its size won't be affected by text zoom (though you might need a line-height: 0; or so to be sure), so it doesn't need any padding.
As scunliffe already showed, browsers using page zoom may need sprites to have a little padding due to rounding errors.