Yes, I know this and here I am complete sure all is well. All my other scripts run flawlessly and all permissions in ‘Privacy’ tab are given.
Neither do I but I think Shane expained how it possibly could have happened.
I did that, and hate to say it does not work.
I think my settings are correct in the system. However should anybody have a tip as to what to check I love to hear.
I sincerely apologise if I upset you. I might not be the best AS scripter (I know I am not) but at no time did I intently try to upset the system. I am enormously grateful for the help you and others gave and have given me in the past solving AS challenges. Once again very sorry for the mess.
on open draggedItems
repeat with currentFile in draggedItems
-- change targetBytes value to max file size in bytes
(my resizedJpegFromPath:(POSIX path of currentFile) maxHeightOrWidth:800 targetBytes:100000)
end repeat
end open
use scripting additions
use framework "Foundation"
use framework "AppKit"
on resizedJpegFromPath:imagePath maxHeightOrWidth:maxDim targetBytes:maxBytes
set imagePath to current application's NSString's stringWithString:imagePath
set outPath to (imagePath's stringByDeletingPathExtension()'s stringByAppendingString:"-out")
set outPath to outPath's stringByAppendingPathExtension:"jpg"
-- Get the contents of the passed picture
set theImageRep to current application's NSBitmapImageRep's imageRepWithContentsOfFile:imagePath -- load the file
set theClip to current application's NSPasteboard's generalPasteboard()
-- Extract its original size
set oldHeight to theImageRep's pixelsHigh()
set oldWidth to theImageRep's pixelsWide()
if oldWidth > oldHeight then
set theWidth to maxDim
set theHeight to oldHeight * maxDim / oldWidth
else
set theHeight to maxDim
set theWidth to oldWidth * maxDim / oldHeight
end if
set newRep to (current application's NSBitmapImageRep's alloc()'s initWithBitmapDataPlanes:(missing value) pixelsWide:theWidth pixelsHigh:theHeight bitsPerSample:8 samplesPerPixel:4 hasAlpha:yes isPlanar:false colorSpaceName:(current application's NSDeviceRGBColorSpace) bytesPerRow:0 bitsPerPixel:32)
-- store the existing graphics context
current application's NSGraphicsContext's saveGraphicsState()
-- set graphics context to new context based on the new bitmapImageRep
current application's NSGraphicsContext's setCurrentContext:(current application's NSGraphicsContext's graphicsContextWithBitmapImageRep:newRep)
theImageRep's drawInRect:{origin:{x:0, y:0}, |size|:{width:theWidth, height:theHeight}} fromRect:(current application's NSZeroRect) operation:(current application's NSCompositeSourceOver) fraction:1.0 respectFlipped:false hints:(missing value)
-- restore state
current application's NSGraphicsContext's restoreGraphicsState()
set compFactor to 0.8 -- starting compression value
set compMax to 0.2 -- compression limit
repeat
set theData to newRep's representationUsingType:(current application's NSJPEGFileType) |properties|:{NSImageCompressionFactor:compFactor}
if compFactor > compMax and theData's |length|() > maxBytes then
-- too big, so try with more compression
set compFactor to compFactor * 0.9
else -- give up
exit repeat
end if
end repeat
theData's writeToFile:outPath atomically:true
end resizedJpegFromPath:maxHeightOrWidth:targetBytes:
set anImage to choose file of type {"public.png", "public.tiff", "public.jpeg"}
my resizedJpegFromPath:(POSIX path of anImage) maxHeightOrWidth:800 targetBytes:100000
in your post you said to chance the 100000 to change the output size of the file.
Is this in this line (top)?
(my resizedJpegFromPath:(POSIX path of currentFile) maxHeightOrWidth:800 targetBytes:100000)
Or this line (bottom)?
my resizedJpegFromPath:(POSIX path of anImage) maxHeightOrWidth:800 targetBytes:100000
Or both?
I ask as any changes made in each of these lines or in both at the same time, make no difference. The output is always a 48KB file. For example I tried 1000000000 and 100 no difference.
Or did I not understand you correctly?
PS
I make a new AS doc and paste the whole text in every time. Next save is as an application. No save as or duplicate.
I hate to write that it’s the kind of sentence which really doesn’t help.
Are you writing about the applet with every instructions disabled ?
If it’s that, what’s the meaning of your statement ?
I will deliberately shout. YOU WERE WARNED SEVERAL TIMES THAT WHEN IT’S SAVED CORRECTLY, SUCH SCRIPT DOES ABSOLUTELY NOTHING.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) lundi 25 mai 2020 16:04:54
It sounds like you’ve modified the document, but not saved it. Also, extreme values are a bad test; it will give up before it gets anywhere near 100, and it will start off under 100000000 anyway.
Must I understand that, at last, you were able to get the scripts vents to do what they are supposed to achieve or that you just got the script using ASObjC doing the job ?
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mardi 26 mai 2020 15:17:31
Yvan not sure what you are asking here. And not sure about it using ASObjC, I Googled it and I do not think we are using this here. I surely never installed it.
hopefully this answers your question, what I did is I used the script Shane wrote and combined that without any changes - post number 66 and 56. That shrinks the images I drop on it in 10.15.4.
It is a tick different in the end result compared to my old script results, but one can live with that.
May you retry my scripts using Image Events after applying what Shane urged yo to do in its message #67 ?
Before doing what Shane wrote, you wrote that its script didn’t worked.
I assume that doing the same for mines will give good results too.
When we work with applet/droplet we must apply Save, never rely upon the AutoSave feature.
When I face a problem with an applet or a droplet, every time I solve it with the same boring protocol: open the applet/droplet in the Script Editor
copy all the content of the script window
delete the offending applet/droplet
paste in a new blank script window
save as an application.
To be sure, I asked peavine and he confirmed that on its side, my scripts work flawlessly under Catalina.
So they must do the same on your machine which, I assume, was not made for you with a special design.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mardi 26 mai 2020 17:46:21
I did not know this, I suppose it is proof of my ‘expertise’ in AS.
OK happy to do so.
To prevent misunderstanding, and me taking the wrong one, please be so kind and tell me what the number of the post is it is in. Alternatively, if that is easier for you, post it again.
As I learned from you guys, it was my way of saving/copying the stuff that might have caused the problems.
I too know that now. It now also explains why I have had problems in the past. So one is never too old to learn!
I tested the 3 scripts. 678 and 800 and 1200. All 3 turn the icon picture 90 degrees when finished. However, the original pic is 3.6MB, and the scripts shrink it to 2.5MB and 2.6MB and 3MB respectively.
If I change this line:
scale openedFile to size 800 --<<<< here we define the wanted greater dimension
to
scale openedFile to size 80 --<<<< here we define the wanted greater dimension
I get a 1MB size pic but it is now so small it is hard to see.
The one in Post 55 also works, as reported before, here too it turns the icon and the 3.6MB pic is turned in to 3.5 and 3.1 and 2.6 MB size. And I get the dialog boxes.
See my original script kept the picture in a workable/viewable format but shrunk its storage size. Which is what I am after.
There is definitely a problem with your machine (or with you).
When, as you did, I drag and drop your original file :1,754,025 bytes – 3264 x 1836 pixels, 72 DPIs
on a droplet containing the instruction: scale openedFile to size 80
I get logically a small file : 4,826 bytes – 80 x 45 pixels, 72 DPIs
It’s normal that it’s a small one because the edited script asked it to return a file whose greater dimension is 80 bytes what is really done.
An other detail puzzle me: I saved two versions of the droplet.
One of them contains : save openedFile without icon
The other one contains : save openedFile with icon
The created file is the same in both cases and it has no icon.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mercredi 27 mai 2020 10:59:03
The original file is :
4000 x 6000 pixels, 72 DPIs,
file size reported by Preview: 3,203,298 bytes,
file size reported by Finder: 3,203,298 bytes,
no resource fork.
your treated file:
53 x 80pixels, 72 DPIs,
file size reported by Preview : 2535 bytes
file size reported by Finder : 745,102 bytes
resource fork : $B54A7 bytes (the icons data)
my treated file:
53 x 80pixels, 72 DPIs,
file size reported by Preview : 2535 bytes
file size reported by Finder : 2535 bytes
no resource fork.
With these infos, things become more clear.
(1) When the inspector of Preview display a “file size”, it’s the size of the data fork component, not the size of the complete file.
(2) The data fork is the same in your treated file and in mine.
So, now, I know that the Image Events resizing task is correctly achieved on both machines.
It would be fine to know what is the size reported by the Finder if you apply this edited version:
on open draggeditems
tell application "Image Events" to launch
repeat with currentFile in draggeditems
tell application "Image Events"
set openedFile to open file (currentFile as string)
scale openedFile to size 80 --<<<< here we define the wanted greater dimension
save openedFile -- with icon -- <<<< don't ask for an icon
close openedFile
end tell
end repeat
end open
In theory you would get:
53 x 80pixels, 72 DPIs,
file size reported by Preview : 2535 bytes
file size reported by Finder : 2535 bytes
no resource fork.
Now, the question is : why am’I not getting the resource fork describing the icons on my side ?
I will try to find what explain this behavior.
Maybe it’s due to the fact that, on my machine, the Finder is set to display icons built on the fly according to the data fork content.
In the pane allowing us to rule the display of windows, the lower checkbox entitled :
“Show icon preview” is checked.
I will search if there is, somewhere, a preference preventing the system to create the resource fork supposed to store the icon.
At least, I’m reassured, the script actually works properly.
Of course, if somebody has an idea explaining why it doesn’t create the resource fork on my machine, I’m all ears.
I’m a little bored to discover that the “surprising” behavior was not on your machine but on mine.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) jeudi 28 mai 2020 11:09:26
I am presently not at the machine where I have been testing, but will as soon test the new script and report back, as soon as I have access.
You are a kind of detective eh? Wow, what you all discovered. What you say makes sense and is interesting to see how both OS’ behave differently. I now also understand why it is when I pack a pic in an email that all of a sudden Outlook reports a different size. And I am happy to hear you found it and it was not part of my stupidity.
PS for those of you reading this, Yvan and I are exchanging files via private email. This is one of such files he refers to here.
under 10.9.5, the icon is created
my old 10.10 HD no longer boot
my old 10.11 HD no longer boot
under 10.12.6, the icon is not created
under 10.13.6, the icon is not created
under 10.14, I don’t know
under 10.15.4, the icon is created
As Shane Stanley wrote, maybe Apple made changed upon Image Events or the underlying framework.
Of course, I would be glad to know the behavior under 10.10, 10.11 and 10.14.
Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) jeudi 28 mai 2020 15:06:40