I'm trying to get many large (48x48, 256x256, etc.) icons from an exe file and place them in a ListView control. Icon.ExtractAssociatedIcon() only gets a 32x32 image which is too small, are there any alternative methods I could use? I've looked at solutions like this but they don't work.
Related
Hello I made a spritesheet in photoshop. The process to make the spritesheet was fairly easy. The issue is when importing to Unity I get a white background and I don't know how to remove the white background from my spreadsheet in unity. I have taken the following steps to resolve this issue
First unchecked the background in photoshop.
Second I tried to remove background from each individual image in photoshop.
But no luck can someone help.
You can select the asset and change its type to Sprites, instead of Default (in the Inspector); if you've already done that, how about trying .png files?
In one of the updates to Unity of last year, they removed the option to use the image transparancy as alpha when using .psd files. The option was a checkbox in the import setting of the image, which is no longer shown.
You can however use an import preset with a preset that still has this option set.
What you can do is:
Create a preset when in the texture-importer panel. How to make a preset? What is the texture-import panel?
Open the file which was created (e.g. myimporter.preset). You could use a file explorer in your project and search for the name
Then set these values to 1:
propertyPath: m_PSDRemoveMatte
propertyPath: m_PSDShowRemoveMatteOption
Apply this preset to all your psd files inside unity.
Now, importing a .psd file should work fine with transparancies.
Note: Unity's intent was for users to import .png files when dealing with transparancies. But I found it annoying to manually re-import all my .png files when i made changes to the .psd file.
I am currently using GIMP to layer two photos into one photo file for a work project. I have over 7000 107x80 JPG images that I need to place on a 160 x 100 PNG background that has a logo on it and saved as the JPG file name. The 107x80 JPG needs to be placed to the left of the logo on the background. I have been doing this one at a time but it is very time comsuming. I have used BIMP to resize all the JPG images and would really like to find a way to use BIMP to automate this process or find another program that can do this process. I have seen several post about Imagemagick but I am not very good with console based programs. Is there a way to do this in GIMP or another Photoshop program that can do batch processing to place the photo in an exact spot on the background? Would it be better to get Photoshop and do a Macro? Thank you for your help JPG on background Background PNG
You can use ImageMagick to composite one image at some exact location on another image. ImageMagick convert can do this operation and is command line driven. See http://www.imagemagick.org/Usage/layers/#convert. The convert process can be scripted to loop over each of your images. Or if you have the same background or the same overlay image, then you can process a whole folder of files using the mogrify command. See http://www.imagemagick.org/Usage/basics/#mogrify and http://www.imagemagick.org/Usage/basics/#mogrify_compose. If you provide a pair of images and the location where you want the one image to be placed on the other image. I can give you more direct commands.
What are the alternatives to process illustrator files or PDFs into XAML. My Current workflow works like this:
Open the PDF file in Adobe illustrator
Save the file as .ai (Adobe Illustrator) file
Open in Expression Design
Do some processing, mainly separating elements to layers and removing unneeded parts.
Save as XAML
Add XAML to Blend project
My only problem is that this way the text gets converted to paths. I would like to keep my text in XAML as well instead of paths.
Is there any other way to do this, so I keep the text? Any other tools?
I think what you want is to have Glyphs elements instead of Paths.
The problem is that Glyphs elements require you to specify the URI of the font file. Also, Glyphs elements reference glyphs by their index into a font file (it may happen that a converter that generates Glyphs elements - like the Microsoft XPS Document Writer - uses indices into font subset files: so these indices may not be the right indices to the same glyphs as defined in the original font file). I have been able to "solve" this problem in two ways with my own PDF to XAML conversion tools.
1. approach: Embed the font-subset file, BASE64 coded, in the generated XAML code and have the application implement a class that, upon loading, extracts and decodes an embedded font-subset file to a temporary location and hands a valid URI to that temporary file back to the XAML loader.
or, 2. approach: Have most font files already installed along with my application and, again, adding some support by my application that replaces the font name by an URI to the installed font file upon loading of the XAML code. The problem with this second approach is that glyph indices need to be correctly mapped to the installed font file, which may not be all that trivial to do. (You can find a link to an example file that has been generated for this way of loading on my blog: in particular take a peek at the file truncatedcone-xaml.txt)
In short: both solutions require a special PDF to XAML converter and support by the loading application. The reason I wanted to do it this way instead of just having my PDFs converted to Paths only is that my application is a shared whiteboard: thus I want my vector graphics to be as small as possible. (Conversion to paths tends to blow up the XAML code by a factor of 10 or more in most cases).
I am contemplating the implementation of a third approach: this would consist in generating the outline for every glyph that is used only once and then add support by my application to transform and position these glyph outlines in a way closely analogous to what Glyphs elements do that would otherwise have to be generated. The advantage would be that the generated XAML would still be relatively small (comparable to the second approach described above) without requiring the relevant font files to be installed along with the application and without having to map glyph indices from a subset file to the installed font file. The reason I have not yet tried to implement this in earnest is twofold: first, my current (second) approach already works very well for what I currently need; second, there might be performance problems with this third approach as reagards loading and / or rendering.
There's a (free) Adobe Illustrator plugin to export to XAML. Not sure it does exactly what you are looking for, though.
Find it at http://www.mikeswanson.com/XAMLExport/
Well an XPS file is actually a ZIP file. So if you open it with a ZIP-archiver or if you rename its extension to ZIP you can see what is inside. It already contains the pages as XAML code (those files have the form [pagenumber].fpage). However, that XAML code may refer to other files (like raster images and font subset files, those are typically odttf files - basically encrypted true type files) that are included in that ZIP archive as well. Which means, that the XAML code that you find in an XPS document may not be directly usable as pure XAML in your application. I have written python scripts to do the conversion of XAML taken from XPS documents (generated by the Microsoft XPS Document Writer) to get XAML files that my application can load (see approaches 1 and 2 above). I could send you copies of those python scripts (they are not particularly great code, which is no problem for me since I am now using a different approach to convert PDFs to XAML anyway).
#gyurisc: Keeping the font file should work but keeping the text might turn out to be a problem, because, you see, glyphs are not characters. It might be that you could figure out the character by examining the font file that a given glyph is part of, but that would involve parsing the font file. If you are unlucky, your PDF to XPS converter does even not keep enough information in the font subset files to figure out the character a given glyph (very likely) represents.
For example: If I convert a PDF file to XPS with the help of Microsoft's XPS Document Writer, and then try to select a piece of text from that XPS document, I can (only apparently) copy it to the clipboard. However, if I then paste it back into a Word document, I get garbage. Whereas if I select that same piece of text in the original PDF document and paste it into the same Word document, I get reasonably meaningful text. So Microsoft's XPS Document Writer apparently does not care about the interpretation of a "glyph run" as text, and thus it seems very likely to me that the link between the glyph indices that one finds in the generated XPS code and the characters they are meant to represent is already broken at that point. (But, admittedly, that's just a guess.)
A representation of text (as opposed to a run of glyphs) would be a TextBlock element in XAML, I suppose. However, my guess is that a typical PDF to XPS converter is unlikely to generate TextBlock elements. XPS is mainly meant to be rendered - on screen or on paper - it doesn't suggest itself as a file format that is particularly suitable for data exchange (exchange of text in your case).
I'm creating a Custom Google Map based on an image in an Adobe Illustrator file. I need to cut the file into 256px x 256px PNGs to feed into the Google Maps API.
You can write scripts to automate tasks in Illustrator using ExtendScript, a modified version of JavaScript. I found one example of a script for Photoshop that makes tiles for Google Maps (Hack #68 in this book) but I haven't figured out how to port this over to Illustrator.
The main problem is I can't figure out how to tell Illustrator to isolate 256px x 256px portions of an image. The Photoshop script does this by selecting portions of the image of that size and copying them into a new file, but as far as I know you can't do that in Illustrator.
Any ideas?
I've got no experience writing scripts for Adobe products, but since Illustrator handles vector data, the tiling algorithm is slightly different. There is a Python script for MS VisualEarth that tiles a set of GPS points (demo), maybe you can take some ideas from it.
Another choice may be to (programatically?) render .AI files to .PNG or something similar an then tile it into 256x256px tiles using that PS hack you referenced.
I need about 100 icons inside my application. Would it be logical to have one large image file with all the icons and then somehow split it up into individual NSImage objects? Is there a way to run some code at build time to regenerate the individual icons?
Assuming you are indeed using the icons separately, I think it would be more logical to keep them separated, for a couple of reasons:
It might seem more organized to reduce the total number of files, but having one big file with all your icons isn't a terribly organized method of storing them, either. Xcode can deal fine with a large number of icon files.
If you're using version control, it complicates the management of the history a bit. As it stands now, if you need to change an icon, you just change that icon, and you can keep a history of changes to that icon. If the icons are in one big file, then any time you change any icon, that file will show up in the history, so it'll be hard to isolate what changes to what icons you made.
It's probably easier to edit a single icon than a bunch of icons smashed together into one file.
Why write a build script or runtime code to slice up the icons if you don't have to?
100 icons? Woot? Okay,
No it would not be logical. It is possible to split them at runtime, not at build time. I would simply use the easy way and add all icons as different files.