Expected behaviour: An Image option to restrict image by max file size property when an image is uploaded.
Actual behaviour: Currently there is no such option to restrict the image upload by file size.
A workarround option might be detecting content size using javascript:
if (editor.getEditorValue().length > (1024 * 1024 * 1.37))
{
alert('content too big: ' + (editor.getEditorValue().length / (1024 * 1024 * 1.37)).toFixed(2) + ' MB');
return;
}
This can be triggered when saving (custom code) or using jodit events
Related
I have a file (for example JPEG size 1588 × 2244px). It's generated by puppeteer (but phantomjs also generate 72 DPI screenshot). When I save this image into a file with .jpeg extension and I use macOS General Info I see:
As you can see it has 72 DPI set in metadata, but I want to use file with 300 DPI. I know, that in digital it doesn't change anything - it's property for printing, but I don't want to explain to each customer that this file could be print in 300 DPI.
When I use Gimp and Image > Print Size
I can change the DPI, and export a picture again. And now it has 300 DPI in General Info window.
I try to do it in Node.JS server, but I found few options to change this property on .PNG pictures, but anyone is working for .JPEG files.
I think that the most accurate option is to use method changeDpiDataUrl from this library:
https://github.com/shutterstock/changeDPI/blob/master/src/index.js
But when I put my image as base64image, after a split operation I have the array with 1 element only - I think that this is body, so I don't have format property (at 63 line).
Anybody meet this problem before?
You can use the library piexifjs to change the EXIF data of an image. The library only changes the meta data (called EXIF), not the image itself.
Code Sample
The following code uses the API to read the EXIF data of an image, change it and create a new buffer from the changed data.
const piexif = require("piexifjs");
// get the image buffer from puppeteer or from disk
const imageBuffer = /* ... */
// convert buffer to string and load it
const imageString = imageBuffer.toString('binary');
const exif = piexif.load(imageString);
// change resolution
exif['0th'][piexif.ImageIFD.XResolution] = [300,1];
exif['0th'][piexif.ImageIFD.YResolution] = [300,1];
// generate new EXIF data
const newExifDump = piexif.dump(exif);
// generate new image
const newData = piexif.insert(newExifDump, imageString);
const jpgBuffer = new Buffer(newData, "binary");
// write to file or use buffer
// ...
Be aware, that I have not used the library myself, nor have I tested the code.
This solution is another alternative to the answer given by #thomasdondorf.
The resolution/density can be set easily using JavaScript standard image processing library sharp by withMetadata function.
Simple example:
// Set output metadata to 96 DPI
const data = await sharp(input)
.withMetadata({ density: 96 })
.toBuffer();
Npm module: sharp
I have asked the question on the repository directly, but in my experience SO is more reactive.
Hey there,
I am trying to create a pdf from photos using pdfkit.
Depending on whether an image is in landscape or portait mode, I want to turn the image around.
This basically means the following (in typescript) :
function toPostscriptPoint(mm: number) {
return mm * 2.8346456693;
}
const document = new PDFDocument({
size: [toPostscriptPoint(156), toPostscriptPoint(106)],
});
document.pipe(fs.createWriteStream('output.pdf'));
document.save();
document.rotate(90);
document.image(
'photos/sample.jpeg',
{ width: toPostscriptPoint(150), fit: [toPostscriptPoint(150), toPostscriptPoint(100)] });
document.restore();
document.end();
What happens though is that the pdf renders completely white. I do see however that something is happening, because the pdf has the size of the input image.
Is rotation for images not supported? What would be possible alternatives? I would like to avoid having to rewrite my files before putting them in the pdf.
Thanks
Alright, after investigation, I can answer my own question :).
I could see that the images were in the pdf somehow because of the size of the file so I dived deeper.
What happened was that the image was rendered out of the viewport. This was due to multiple things:
By default, the origin of a page after rotation in pdfkit is the center of the page! ( See the doc for more info)
The origin is rotated together with the transformation.
The x and y in the image method are actually inverted.
So after getting all this right, the following code shows the image as expected :
function toPostscriptPoint(mm: number) {
return mm * 2.8346456693;
}
const document = new PDFDocument({
size: [toPostscriptPoint(156), toPostscriptPoint(106)],
});
document.pipe(fs.createWriteStream('output.pdf'));
document.save();
document.rotate(90, {origin : [0, 0]});
document.image(
'photos/sample.jpeg',
toPostscriptPoint(0),
toPostscriptPoint(-150),
{ width: toPostscriptPoint(150), height: toPostscriptPoint(100) });
document.restore();
document.end();
Note the :
origin argument in the rotation
toPostscriptPoint(-150) actually takes into account the position of the origin, and corresponds to the X axis.
Hope that helps some later on :).
Its because taking picture from camera , if picture ISO is less than 100 it will be automatically rotated , take picture with iso more than or equal to 100 to avoid autorotation.
I am using azure web job to save thumb of an image and this is code for doing this
ImageProcessor.Imaging.Formats.FormatBase f;
f = new ImageProcessor.Imaging.Formats.JpegFormat();
Size size = new Size(200, 200);
using (WebClient client = new WebClient())
{
MemoryStream stream = new MemoryStream(client.DownloadData(input));
MemoryStream stream2 = new MemoryStream();
int quality = 110;
do
{
quality = quality - 10;
using (ImageFactory factory = new ImageFactory(false))
{
factory.Load(stream)
.Format(f)
.Resize(size)
//.BackgroundColor(Color.White)
.Quality(quality)
.Save(stream2);
}
} while (stream2.Length > stream.Length || stream2.Length ==100000);
When i add message to queue with this image for example,
job should give me thumb image 200 * 200 but there is trailing black area in top and bottom of resulted image like this which shouldn't be done
Why this is done ???
You're trying to fit a rectangle into a square.
From http://imageprocessor.org/imageprocessor/imagefactory/resize/:
Resize
Resizes the current image to the given dimensions. If EXIF metadata is to be preserved the information contained within will also be updated to match.
public ImageFactory Resize(Size size)
Parameters
size:
The System.Drawing.Size containing the width and height to set the image to.
Passing a 0 for either dimension will omit that dimension.
So, pass in 0 as height to maintain aspect ratio,
Size size = new Size(200, 0);
or use one of the other resize modes: Crop/Min/Max/Stretch
So I have the following script to resize an incoming jpg and save it to the server in a new size. The created jpg file has terrible quality, even when I am making the quality 90 on the imagejpeg. I am wondering if I am messing it up earlier in my efforts.
// Get new sizes
list($width, $height) = getimagesize($filename);
$percentW=298/$width;
$newwidth = $width * $percentW;
$newheight = $height * $percentW;
// Creating a blank canvas to put the new file. Is this an extra step?
$thumb = imagecreatetruecolor($newwidth, $newheight);
$source = imagecreatefromjpeg($filename);
// Now I create the resized photo with the needed width and height on the blank canvas with the source file resized
imagecopyresampled($thumb, $source, 0, 0, 0, 0, $newwidth, $newheight, $width, $height);
// Output to server, define 90% quality. My guess is the quality is destroyed before now.
imagejpeg($thumb,"../../uploads/buckets/" . $_POST["bucket"] . "/" .$fileNameBucket,90);
imagedestroy($thumb);
Am I messing up the quality before I even output the file to the server? Should I use resample instead of resize? I am stuck with using the GD library so ImageMagick is not an option. Thanks.
MFC doc/view architecture, sdi (more precisely multiple top-level windows).
In my view class, I set my "playground" (i.e. logical space) with SetScrollSizes(); Then I want to limit maximum frame window size to that of view's maximum size.
Here is what I'm doing but I think there might be better solution, please advice:
I'm implementing OnGetMinMaxInfo() in my CMainFrame. There I try to get active view's scroll sizes, and set lpMMI->ptMaxTrackSize appropriately. Below is the code:
void CMainFrame::OnGetMinMaxInfo(MINMAXINFO* lpMMI)
{
// Call base version:
CFrameWndEx::OnGetMinMaxInfo(lpMMI);
// Get active view:
CScrollView *pScrollView = (CScrollView *)GetActiveView();
if (pScrollView && pScrollView->IsKindOf(RUNTIME_CLASS(CMyFckinView)))
{
// Get total size of playground:
CSize sizePlayground = pScrollView->GetTotalSize();
// Test if the size is non-zero, i.e. there is at least one node displayed:
if (sizePlayground.cx && sizePlayground.cy/* && !IsPrintPreview()*/)
{
// Set maximum window size to match our playground size:
CRect rectClient, rectWindow;
pScrollView->GetClientRect(&rectClient);
this->GetWindowRect(&rectWindow);
if (rectWindow.top > -5000 && rectWindow.left > -5000) // Avoid when minimized...
{
lpMMI->ptMaxTrackSize.x = sizePlayground.cx + (rectWindow.Width() - rectClient.Width());
lpMMI->ptMaxTrackSize.y = sizePlayground.cy + (rectWindow.Height() - rectClient.Height());
return;
}
}
}
}
This works but has one problem: When print preview is displayed (standard MFC print preview), I obviously want to allow free window resizing, so I use runtime info GetActiveView()->IsKindOf(...) to determine that active view is really my view, and not print-preview's view (which is CPreviewViewEx). But when I close the print preview, OnGetMinMaxInfo is not called, so I'm unable to adjust frame size according to my view again. As soon as I move the window OnGetMinMaxInfo gets called again and correctly adjusts frame size, but without manually moving the window old size (to which the print preview was sized to) is retained and has ugly artifact.
What can I do? Basically if I could trap the moment when print preview is closed, I could use following trick:
// Trigger the WM_MINMAXINFO message:
CFrameWnd *pFrame = GetParentFrame();
RECT rectWindow;
pFrame->GetWindowRect(&rectWindow);
pFrame->MoveWindow(&rectWindow);
But I don't know how to trap print-preview closure.
What I'm trying to accomplish seems quite standard: who would want to have frame window resized bigger than view's logical size (set by SetScrollSizes())? So there should be some more natural solution maybe?
In your CMyFckinView, handle a message that is reliably sent when the print preview is closed and then post a user message to the mainframe which will trigger your "force minmax" code. Perhaps WM_FOCUS or WM_ACTIVATE?