I'm having trouble getting .APNG files to work - they preview correctly in Firefox (meaning when drag'n'dropped into a Firefox window, they animate the way they're supposed to) but when I drag'n'drop the same file into xcode, I see only the first frame. No animation. When previewing in a simulator, no animation - just a static sticker.
The same files animate correctly in an iMessage timeline when sent as attachments (like animated GIFs)..so the files are good.
Also, it's not a size issue - one of them is 16 Kb, and about 400x260. Some are larger in file size but smaller in frame size, none are over 350 Kb.
It's just Xcode that doesn't like them.
I know how to make animated sticker packs - I have two for sale already. For those, I used PNG sequences. I'm trying to use .APNG files because I'm getting way better compression.
I've used PNG Animator as well as apngasm to create the .APNGs, and they are all at or under 300 Kb in size, and under 600 pixels in size.
Is anyone successfully using .APNG files for creating animated stickers?
KM
https://itunes.apple.com/us/app/markup-stickers/id1157027020?mt=8
UPDATE! GOT IT TO WORK!
I needed to import them as stickers, or static image files, and NOT as a sticker sequence, and also needed to name them .PNG and not .APNG.
Success!
KM
Related
I'm updating an existing macOS app with new images.
One of them is a vector image in PDF format. When I add the PDF to an image set, Xcode determined a size for it:
The existing dialog has a larger image, so this new one renders smaller. However, I should be able to scale it to whatever size I like as it's a vector image.
It seems the size comes from metadata in the PDF file. The Inspector in Preview shows:
Are there tools I can use to tweak those values? I don't want to resample the PDF or use tools like ImageMagick - as I said, this is a vector image.
After long struggle I managed to generate (using Ant) on MacOSX (Yosemite) a DMG (of modular JavaFX application that deploys to *.app folder) even with custom icons of the app and DMG volume (both stored as *.icns files in build's package/macosx folder). Drag and drop works, it installs the app, the app launches so everything is fine. Well, almost.
I was tempted to make also the custom background for DMG. It is placed together with the icons in package/macosx folder as App-background.png file (where App part is the name of my app, as it is with icons). And javapackager actually picks up the background, but unfortunately after opening DMG the background seems to be placed in windows' top-left corner, the window itself is like twice the size of the background, so 3/4 of the window's background is just white.
I tried with different PNG sizes, but to no avail. DMG window is always way bigger than the image.
Is there any way to make javapackager (aka fx:deploy which I actually use) to generate DMG with proper settings, that just make the DMG window fit background size?
Edit: It seems like DMG window has actually the size of the PNG (the original background file), but for some reason the image, when displayed as background, is "slightly" scaled down.
After long investigation I found the (not so obvious and rather not direct) reason for this misbehavior. Fortunately I found also the solution.
Apparently there's some problem with Finder handling PNG while displaying DMG file. It all comes down to chunk pHYs which contains 3 fields (4b, 4b and 1b long respectively). It is pixels per unit on x axis, pixels per unit on y axis and 0 or 1 for unit (0 no unit, 1 a meter unit). Playing with these values (via hex editor) did change somehow scaling behavior (and window size), but I wasn't able to figure out correct values. Eventually I get rid of this chunk completely (exporting from GIMP as PNG without saving resolution) and that solved the case.
So for anyone struggling with this: just make sure, there is no pHYs chunk in PNG file.
Edit: One can do that easily with ImageMagick:
$ convert image.png -define png:exclude-chunk=pHYs image.png
This strips pHYs chunk from the image.png file.
I've got an RTF file with an embedded image in it. The image is scaled by 2/3, or 0.67. It displays correctly in Word, but when the file is printed it consistently displays by ignoring the scale setting.
The source image is a PNG with dimensions 297x117 (pixels). The image was originally encoded as follows:
{\pict\pngblip\picw7858\pich3096\picwgoal4455\pichgoal1755\picscalex67\picscaley67
<Hex-encoded PNG image>}
The original picture width/height is calculated as (w,h) * 2.54 * 1000 / 96 (twips).
The original picture width/height goal is calculated as (w,h) * 1440 / 96 (twips).
A twip is 1/1440 inch and 2.54 is the number of centimetres in an inch.
I edited it to try setting the size manually. I multiplied all of these values by 2/3 and removed the \picscale[xy]67 instructions:
{\pict\pngblip\picw5239\pich2064\picwgoal2985\pichgoal1176
<Hex-encoded PNG image>}
However, it still seems to only use the size of the PNG (297x117) when printing it. The screen display and the print result both appear unchanged from before.
Other than manually rescaling the image and re-embedding it into the RTF, can I get the printed version to respect the scaling?
UPDATE
I did try embedding an image resized to 2/3 of the previous dimensions, but the printed image is still 50% larger than the on-screen image (the extra area gets cropped). The only difference is that it was much lower resolution.
I also tried the same image in a Word document and it printed perfectly, so it's definitely a difference between .docx and .rtf files. Is it perhaps a dpi setting in the PNG image?
Windows 10 updated itself last night, and now I can't replicate the problem. All old files that previously had this problem, no longer have this problem. Go Microsoft!
It appears to be this update that resolved the issue: https://support.microsoft.com/en-au/help/4093112/windows-10-update-kb4093112
Addresses an issue with printing content generated by ActiveX in Internet Explorer
There's no more information about this, but it is related to printing.
I have a report that renders images (jpg) that have been collected from various sources. This works fine within the report viewer, and when exporting via Excel.
However, when exporting to PDF, about 5% of the images are rendered incorrectly as can be seen below, with the original on the left, and what is rendered on the right;
I find that if I open up one of these images in mspaint, and just click save, on the next report-run the image is now rendered correctly.
Are there any rules as to what image properties/format are valid for SSRS to render the image correctly within a PDF? Essentially I'd like to somehow find these images that will render incorrectly before the report is run and fix them prior...
Current Workaround
I never ended up getting SSRS to display the the problem images as they were, however, determining before running the report which images would be included in the non-displayable set so they could be converted to a supported format (automatically) was also a solution.
In my case, all images were supplied via users uploading to a website, so I was able to identify and convert images as they arrived. For all existing images, I was able to run a script that identified the problem images and convert them.
Identifying problem images
From the thousands of images I had, I was able to determine that the images that wouldn't render correctly had the following properties:
Image had CMYK colorspace or;
Image had extended color profiles or;
Both of the above
Converting an image
I was originally using the standard .NET GDI (System.Drawing) to manipulate images however the API is often prone to crashes (OutOfMemoryException) when dealing with images that have extra data. As such, I switched to using ImageMagick where for each of the identified images I:
Stripped the color profiles and;
Converted to RGB
Note that the conversion to RGB from CMYK without stripping the color profiles was not enough to get all images to render properly.
I ended up just doing those items on every image byte stream I received from users (without first identifying the problem) before saving an uploaded image to disk. After which, I never had the rendering problem again.
Because of the way the output looks I would say those JPEG images have CMYK colorspace but the SSRS assumes they use RGB colorspace and sets the wrong colorspace in PDF.
If you can post a JPEG image and a sample PDF I can give you more details.
I've had exactly the same problem with an image rendering correctly on screen but appearing like the one in the question when I exported the report to PDF. Here's how I solved it.
The Problem
The first clue was this article I came across on MSDN. It seems that regardless of the original image density, the PDF renderer in SSRS resizes all images to 96 DPI. If the original size of the image is larger than the size of the page (or container), then you will get this problem.
The Solution
The solution is to resize the source image such that it will fit on your page. The requires a little calculation depending on your page size and margin settings.
In my case, I'm using A4 paper size, which is 21cm by 29.7cm. However, my left margin is 1.5cm, and my right margin is 0.5cm, for a total inner width of 19cm. I allow an extra 0.5 cm as a margin of error, so I use an inner width of 18.5cm.
21 cm - 1.5 cm - 0.5 cm - 0.5 cm = 18.5 cm
As noted before, the resolution generated by the PDF renderer is 96 DPI (dots per inch). For those of us not in the United States or Republic of Liberia, that's 37.79 DPC (dots per centimetre). So, to get our width:
18.5 cm * 37.79 dpc = 699 pixels
Your result may be different depending on (1) the paper size you are using, and (2) the left and right margins.
As the page is higher than it is wide, we need only resize the width while keeping the image proportional. If you're using a paper size which is wider than it is tall, you'd use the length instead.
So now open the source image in Paint (or your image editor of choice), and proportionally resize the image to the desired width (or length) in pixels, save it, import it into your container, and size the image visually with respect to the container. It should look the same on screen, and now render correctly to PDF.
This is an issue reported to Microsoft Connect.
From SSRS 2008 How to get the best image quality possible?:
The image behavior you see in PDF is a result of some image conversions that the PDF renderer does, based on how the PDF specification requires that serialize images into PDF.
We know it's not ideal, and we classify the loss of image quality as a product issue. Therefore, it's difficult to really say what to do to get the best quality image.
Anecdotally, I have heard that customers have good results when the original image is a BMP
I'm an experienced developer but a relative newbie with Cocoa. The Cocoa documentation says that toolbar items (NSToolbarItem) are 32x32 in regular size and 24x24 in small size. It goes on to say that you can (and should) include an image that includes both sizes and that a multi-page TIFF or an ICNS file can be used. This is where I am confused. I have tried several different programs that create ICNS files but all of them create files including 16x16, 32x32, and bigger. Is the assumption that the 24x24 toolbar icon uses a 16x16 image or is there a way to create a ICNS file with a 24x24 image? Or are people using an application to create multi-page TIFF files?
Use Icon Composer.app and supply the 16 and 32 sizes. The system will automatically up- or down-scale between them as needed and usually does a very good job of it.