I am new in TYPO3, and I am trying something simple, add an image.
Iam doing the following:
I added Content Element "Text & Images"
In the tab "Images" i uploaded an image 1920 x 262
Save
The image loaded is the resolution 600 x 81, i don't understan why.
In the properties i try set 1920 in the field width but same.
In the future i want to know how establish the srcset but first the simple.
(sorry my english)
Sorry to confuse you but there are some rules applied to the maximum size which date back to those days where 600 was already quite large.
the following typoscript constants are relevant:
styles.content {
maxW = 600
maxWInText = 300
}
Depending on the selected value of the field Position and Alignment, one of those 2 applies. So If e.g. "in text, right" is selected, the maximum width is 300.
As a solution you can override the constants to same values which fit more properly.
Most people don't use the default content elements anymore and create custom ones using extensions like mask or dce or without any 3rd party code.
Related
I am programming a website in nuxt and to optimize the images I use nuxt-img.
By optimizing the site with Google Page Speed I saw that the performance value penalizes me because it marks me that the images I use on the site do not have an explicit "height" and "width" tag (see photo).
I set the width and height of the images via the class in the css because they must have relative width and height (eg%, vw, vh) and the height and width property of nuxt-img only accepts "px".
Anyone know how to fix? I don't find anything in the documentation
I have the following
<nuxt-img
id="imgl"
class="bn-img-left"
src="/team/TeamBW.webp"
loading="lazy"
sizes="sm:100vw md:50vw lg:100vw"
alt="Team Adapto bianco nero a sinsitra"
>
</nuxt-img>
Did you read that one? https://v1.image.nuxtjs.org/components/nuxt-img
This is how you define your images, you give it a value in w (pixels pretty much) or vw, then you can pass an aspect-ratio to it. But it's never fully responsive on both axes.
There are quite of articles on the web regarding that question: https://web.dev/learn/design/responsive-images/
That one is also interesting: https://jakearchibald.com/2022/img-aspect-ratio/
The idea is to provide various resolutions to the browser so that it can choose the closest one fitting the needs. Then, there will be some small differences caused by the weight difference (if an image fall in the middle of 2, size-wise).
The Problem
I am loading the classic serife.fon file from Microsoft Windows using FreeType.
Here is how I set the size:
FT_Set_Pixel_Sizes(face, 0, fontHeight);
I use 0 for the fontWidth so that it will be auto-calculated based on the height.
How do I find the correct value for fontHeight such that the resulting font will be exactly 9 pixels tall?
Notes
Using trial and error, I know that the correct value is 32 - but I don't understand why.
I am not sure how relevant this is for bitmap fonts, but according to the docs:
pixel_size = point_size * resolution / 72
Substituting in the values:
point_size = 32
resolution = 96 (from FT_Get_WinFNT_Header)
gives:
pixel_size = 42.6666666
This is a long way from our target height of 9!
The docs do go on to say:
pixel_size computed in the above formula does not directly relate to the size of characters on the screen. It simply is the size of the EM square if it was to be displayed. Each font designer is free to place its glyphs as it pleases him within the square.
But again, I am not sure if this is relevant for bitmap fonts.
fon files are exe files with a fnt payload, where the fnt payload can be a vector or raster font. If this is a raster font (which is most likely) then the dfPixHeight value in the fnt header will tell you what size it's meant to be, which is exposed by FreeType2 as the pixel_height field of the FT_WinFNT_Header.
(And of course, note that using any size other than "the actual raster-size of the FNT" is going to lead to hilarious headaches because bitmap scaling is the kind of madness that's so bad, OpenType instead went with "just embed as many bitmaps as you need, at however many sizes you need, because that's the only way your bitmaps are going to look good")
The FNT-specific FT2 documentation can be found over on https://www.freetype.org/freetype2/docs/reference/ft2-winfnt_fonts.html but you may need to read it in conjunction with https://jeffpar.github.io/kbarchive/kb/065/Q65123 (or https://web.archive.org/web/20120215123301/http://support.microsoft.com/kb/65123) to find any further mappings that you might need between names/fields as defined in the FNT spec and FT2's naming conventions.
I want to automatically add height and width attributes to all my images. It is perfectly done via this nice plugin, but I host my site on GitHub Pages where external plugins are not supported.
Question: How to prefill height/width attributes of an image without using a plugin?
Why do I need this?
My site works well even without height and width but I want to specify them because it is important from SEO point of view (you can find some details on its importance here).
Writing an internal filter to do this using the fastimage gem is fairly simple. You can define your filter in the _plugins directory of your project (this is outlined in the Jekyll documentation)
As a very rough example, you could do something like this:
require 'fastimage'
module ImageSizeFilter
def image_size(source, dimension = nil)
# Get the image dimensions, throw an error on failure
# NOTE: You may want to sanitize the input string provided here
# see: https://github.com/sdsykes/fastimage#security
size = FastImage.size(source, raise_on_failure: true)
# Return the requested dimension, or both dimensions if nothing was specified
return size[0] if dimension == 'w'
return size[1] if dimension == 'h'
return size unless dimension
# Fail if the requested dimension is invalid
raise 'Invalid image size dimension requested: ' + dimension
end
end
Liquid::Template.register_filter(ImageSizeFilter)
Which would be used like so:
<img src={{source}}
width="{{source | image_size: 'w'}}"
height="{{source | image_size: 'h'}}"/>
Of course this still won't work with GitHub pages directly because custom plugins are not supported. To use custom plugins in general, one solution is to build the site locally and include it in the repository.
This question seems to apply to content images in markdown files. These images have no width or height set by default.
The short answer
You can just set the width and height directly in HTML in your markdown, like this:
# Markdown title
paragraph
<img src="/path/to/image.jpg" width="400" height="300" />
The long answer
You cannot retreive the width and height of the image programmatically without a plugin, so when you use (pure) markdown you get an image without a width and height property. The question is WHY you wanted to add a width and a height in the first place. Setting the width and height prevents reflow, but it leaves a big gaping hole while loading. Is that truly better? It certainly does not look nice. Progressive JPG's are a very nice solution for this problem, but I do not prefer to set the width and height on them, as 'no image' looks good, and a progressive JPG also always looks good.
You say you want it for SEO reasons, but I cannot think of any.
If your website is so slow you actually want to interact with content below the image before the reflow, the logical solution is to make your website load faster.
However, if you have users with a really slow connection, you might want to manually add the image to the markdown in HTML. See the short answer for a code example.
The Xcode asset catalogue editor supports an Alignment property for images. It very much seems like this is intended as a mechanism for setting a UIImage's alignmentRectInsets, and Apple's Asset catalogue reference strongly suggests this too:
alignment-insets
Dictionary
The insets for alignmentRectInsets in UIImage or for alignmentRect in NSImage. The inset tag can be omitted.
However, when I load images from a catalogue that I've set an Alignment on with the editor, it don't get an alignment.
I'm loading images using [UIImage imageNamed:].
Is this a known bug, or is there some subtlety I am missing?
I've done some testing and I think I've found why it wasn't working.
There's a (small) Bug
If you don't set all of the alignment values in the asset catalogue editor to something other than 0, then none of the alignment values will be honoured when you load that image resource. As it is perfectly reasonable for some alignment values to be 0, I believe this is a bug and I'll raise it on Radar. However – this said, the feature is still pretty useful and I plan to use it.
Pixels & Points
It's worth knowing that the Alignment, that you set in the asset catalogue editor for a multi-scale PNG, is defined in pixels and not in points.
When you load the asset and then ask the image for its alignmentRectInsets, the result is reported in points. Ie, the scale factor of that particular asset will be applied to the values that you set in the editor.
An example: if you set an alignment of 30, 30, 30, 30 on your #3x asset, then load the UIImage, you'll see it's alignmentRectInsets are 10, 10, 10, 10.
Vector Assets
I also tested a vector asset. Here, you have one vector image, and you specify one set of alignment values for it.
In this case of a single vector asset, the Alignment in the asset catalogue editor is defined in points and not in pixels. This is the opposite situation to a multi-scale PNG!
When you load the asset and ask for its aligmentRectInsets, then you'll see the same values reported, regardless of scale the UIKit loads for that image.
… This actually makes sense, and wouldn't work if done differently. But it seems like it might catch people out.
I'm using Flying Saucer for HTML to PDF conversion. I need to produce an output PDF with 600dpi in Letter size. How can I achieve this?
There are four different factors at play, and they are all interrelated:
Target Page Metrics
You want the page metrics to be correct, so that when you ask Flying Saucer to produce a "letter" size page, the resulting PDF will show up in Acrobat as measuring 8.5" x 11". You configure the page size directly in FS by specifying the page-size property in your CSS, as obourgain noted in the other answer: #page { size: letter; }
Resolution
You want the final output to be suitable for printing on some printer at a certain XXX dpi. This is all well and good, but remember that PDF is (mostly) a vector format. I didn't check the spec, but as far as I know, the PDF file/page don't "have" resolution because they are vector-based. That having been said, things placed inside the page have an effective resolution, so we'll need your desired XXX dpi number to calculate the numbers below.
Dots per point
In the FlyingSaucer (and Java) world, a point is always a constant 1/72 of an inch. Period. So we can calculate the dots-per-point value by taking the desired resolution and dividing by the size of a point. For example, if you want 300 dpi output:
dots-per-point = 300 dpi / 72 ppi = 300 dots/inch / 72 points/inch = 300/72 dots/point = 4.1666 dots/point
Dots per pixel
This is not a magic number and this value is directly related to the dots-per-point number, as well as the expected resolution of the graphical images that you are trying to feed into FlyingSaucer. More specifically, given a graphic image that is X x Y pixels in dimensions, you need to decide how big you want that to render in your PDF. If you are using an image that was prepared for screen (web) use, you probably are starting out at the standard 96 pixels/inch (so a 96 x 96 px image would render as a one-inch square on the PDF output).
So we can easily calculate dots-per-pixel as follows, again assuming we wanted 300 dpi output:
dots-per-pixel = dots-per-inch (dots) / pixels-per-inch (pixels)
dots-per-pixel = 300 dots/inch / 96 pixels/inch = 3.125 dots/pixel
If you go this approach, your images will be sized correctly, but they won't be the 300 dpi print quality that you're looking for. That's because your images were not of high enough resolution to begin with. More on that in a minute.
Getting it all set up
If you just call SharedContext#setDPI directly as suggested in one of the other answers, you'll likely get the wrong results. This is because it doesn't make logical sense to change the dots-per-point without also changing the resolution (dots-per-inch). The ITextRenderer constructor makes a fixed call to setDPI(72*dotsPerPoint), and when it goes to create a new page, it also uses the dotsPerPoint value set by the constructor to calculate the correct page width in points. If you have changed the resolution under its nose by calling setDPI, you'll end up with the wrong page size.
The correct way is to create a new ITextRenderer object using the values we calculated above. If we wanted 300 dpi output and we had 96 ppi images to feed it, we would call:
ITextRenderer renderer = new ITextRenderer(4.1666f, 3);
Note that the dots-per-pixel parameter only accepts integers, so we're rounding 3.125 to the closest integer above. However...it's truly the ratio between the two numbers that seems to be important, so to make the last argument an integer, we can multiply both numbers by 8 (the lowest integer multiplier that yields an integer), which gives 33.3333 and exactly 25. This also is my guess for the origin of the magic "20" number in the Flying Saucer sources.
Check your output
By this point, your output PDF should look pretty much the same as it did when you started (assuming that you were previously using the default 96 ppi configuration of Flying Saucer). But now we know the parameters that we need to tune to make everything work.
To get high-quality output, you need high quality input
So we've verified that the above parameters work for our purposes, but our images are still a lowly 96 ppi. If we want to print this stuff at high resolution, all you need to do is swap out the images for 300 ppi versions, change the constructor parameters, and then you're done, right?
Maybe. Let's work through the numbers:
Your expected output resolution (300 dpi) does not change, so dots-per-point is still 4.1666. But your input images are now at 300 ppi, so your dots-per-pixel = 300 dots/inch / 300 pixels/inch = 1 dot/pixel. So you'll now call the constructor like this:
ITextRenderer renderer = new ITextRenderer(4.1666f, 1);
Once you do this, your new 300 px x 300 px image will end up as 1" square on the PDF, which is exactly the print quality you wanted.
But wait! All of my text got really small too!
Flying Saucer uses the dots-per-pixel measurement to convert a number of things, not just images. In particular, if you have specified anything in your stylesheets that uses pixels, the dots-per-pixel measurement will have an impact on their sizes too.
If you have stylesheet rules like font-size: 10px; then increasing the dots-per-pixel supplied to the constructor will make that text smaller, which is probably also not what you want. After all, you should be able to increase the resolution of the images in your PDF while leaving your text in the same size and place.
The answer is to convert everything in your stylesheet to use points. (Or inches. At least something other than pixels!) If you started out with the default Flying Saucer settings (meaning pixels are 96 ppi), you simply need to convert all of your "px" measurements into points. Since 72 points = 1 inch, you would change "px" to "pt" and multiply the value by 72/96.
For example, the font-size: 10px; above would become font-size: 7.5pt;. If you want true consistency with what you had before, everything in your CSS that mentions "px" (as well as any inline styles) must be changed into "pt" with the the same conversion too.
Once you have made this change, your text and other layout will be consistent, and if you decide that you need 600 dpi output later, you can just adjust your images and change the constructor argument, but the rest of the layout will still remain constant. Done!
You can set the letter size with the CSS page size property in your HTML document:
#page {
size: letter;
}
You can change the dpi of the document using the following ITextRenderer constructor :
public ITextRenderer(float dotsPerPoint, int dotsPerPixel)
I don't understand what those values really represent, but default values are dotsPerPoint = 20f * 4f / 3f and dotsPerPixel = 20, and it will output a 96dpi document.
To get 600dpi, you can use dotsPerPoint = 500f / 3f and dotsPerPixel = 20.
Looking at the code of ITextRenderer, the final dpi is given by the formula: dpi = dotsPerPoint * 72 / dotsPerPixel.
A simpler answer for setting the DPI when using Flying Saucer:
renderer.getSharedContext().setDPI(600);
As with obourgain's answer, to be used in conjuction with the #page { size:letter; } CSS.
Source