This is a multi-part question to SO folks before I engage more with core team.
Summary: On OS X, pdfs should be created using quartz, not postscript. Files are smaller, anti-aliased better, OS fonts including opentype are readily available, encoding is less painful, overall I think it’s a better device. On other platforms, it would be reasonable to use cairo, again a more modern pdf-writing device.
Consider the behavior of the png() device. Although it is allegedly slated to move out of x11.R, it handles c("cairo", "Xlib", "quartz") with a default (options("bitmapType")) set by zzz.R (quartz if capabilities("aqua"), cairo if available, Xlib otherwise). PDF needs to behave the same way, so that in Sweave (or babel or whatever) my pdf figures can be generated using the appropriate device.
My Sweave png patch works because png() takes care of getting the device option. An earlier version of the patch (which I still use) flips the device in Sweave, but I was smacked down for this and I know it’s sort of the wrong the place to do it.
There’s some alias cairo_pdf() (also in x11.R) that probably should not be there, shouldn’t that be merged into a device-switching pdf() ?
One approach is to add option "pdfType", which in turn I think should probably be more general – there is already a default device, it’s just that pdf() ignores it! I’m especially wary of introducing new global options because they are more likely to be rejected by core.
I don't think you'd need to implement a device driver. Mostly it sounds like you want to alias pdf() so that it calls quartz() or cairo() as appropriate. The quartz() device already supports PDF output to a file (among others) on OS X.
For your own personal use (I doubt this would find its way into core) you could just alias pdf() to take the appropriate action on each of your platforms and bring it in as a package or in your Rprofile.
pdf.orig = pdf
pdf = function(...) {
// Insert code here
}
Related
On FEI machine, dark field tilts are done by changing "beam LX", "beam LY", "beam UX", "beam UY" defelectors. Are there commands to access this tilt?
I tested out using EMGetBeamTilt(x,y). There is no change on those numbers when changing DF tilt.
Also tried "void EMGetProjectorShift(number x, number y)". This command does not exist in GMS 1.x.
Using "EMSetBeamTilt(x,y)" works to achieve the similar result. I am looking for that way to emulate the DF control used on FEI. Reason 1 is the speed. EMSetBeamTilt is very slow on FEI. Reason 2, hysteresis is strong. Reason 3, it is nice to sync the hardware knob and the script to enhance interactive capability.
GMS 1.x is very, very outdated (on par with WinXP) and didn't even have a supported script-interface for microscope control. (It did have unofficial commands though.)
Microscope control commands were officially introduced and supported with GMS 2.3 ~2012 and going forward, but they are limited in nature as they represent the common denominator of various microscope vendor's hardware interfaces. (i.e. they have to work with all microscopes).
Documentation has since been pretty up-to-date, with some commands being added over time in higher GMS versions. So the short answer to the actual question is:
You have the commands that are documented in the F1 help documentation and there are generally no additional commands.
Depending on your system there might be crude workarounds, though.
f.e. if you system has it's own interface for Python or VisualBasic, one can write a script command to call those interfaces. (Python since GMS 3.4)
I'm trying to compile a project (tyr-quake) with my custom build of SDL2. My SDL2 build among other things disables all accelerated video (OpenGL, OpenGLES, Vulkan, Metal, etc), X11 and Wayland, but enables KMSDRM.
All is well, and the project I wanted to compile with this build of SDL2 compiled too. Except that when running, SDL_CreateRenderer returns Couldn't find matching render driver (even if I modify the source to pass it SDL_RENDERER_SOFTWARE and set the SDL_HINT_FRAMEBUFFER_ACCELERATION hint to "0").
I looked around the SDL source code a bit, and the software SW_CreateRenderer is indeed being called, but later on (in SDL_CreateWindowTexture) it still wants to create a renderer using a different render driver (it explicitly avoids the software one).
I also tried patching the source code to do the following:
SDL_Surface *surface = SDL_GetWindowSurface(sdl_window);
renderer = SDL_CreateSoftwareRenderer(surface);
But that also failed, as SDL_GetWindowSurface fails with No hardware accelerated renderers available and returns NULL.
My question is: is there a way to only have software rendering with SDL when using KMSDRM, or am I required to have some hardware accelerated rendering option enabled and available.
I think I figured this out on my own.
It is not possible to do so. But, if one wants to do that, implementing CreateWindowFramebuffer, UpdateWindowFramebuffer and DestroyWindowFramebuffer, and setting the appropriate function pointers should grant you the ability to create a purely software-based renderer. Sadly, I don't know KMS and DRM enough to be able to implement this myself.
I would like to update my app to support the downloading of PDF documents, but am worried primarily about 2 things:
1: that the user will attempt to use my app to download non-PDF, or virus-riddled items.
2: that said virus riddled-items could infect the device.
I may just be paranoid, as I assume the sandbox would prevent most malware from escaping and screwing with the OS, Kernel or the Lower Level Processes but you can never be too sure. So my question is twofold: How can I (at least mostly) guarantee the download of only PDF's and do it as securely as possible.
(P.S. the download will be done through any generic website in a webView, not a server seeing as I shudder at the thought of web development).
Based on ozdrgnaDiies' answer, I have found this sample code; which I will be modifying to suit my needs, thank you. http://iphoneincubator.com/blog/server-communication/how-to-download-a-file-only-if-it-has-been-updated
From what I've gathered from your question, I assume you want to check if the file you are downloading is a pdf and not anything else? If so, you could check the header of the file to verify it is a pdf.
Example, the first thing in every .pdf (That I have myself) is:
%PDF-*.*
Where *.* is a version(?) number. For example, 1.2, 1.3, 1.5, etc.
Therefore, reading the first 5 characters from a downloaded pdf should result in "%PDF-", otherwise it is not a pdf.
As more examples, the first thing in a jpeg image is:
ﾘ・
And for an .exe it's:
MZ・
etc
iOS apps are sandboxed. Meaning, anything you do within the app should only affect your app. Unless you attempt to somehow run the downloaded content (which I believe is against the rules for the App Store). The only thing left would be maliciously crafted PDFs…
I personally don't think it would be a big issue.
I have an app in which the app bundle contains an image file (I mean that the file is dragged into XCode and appears in "Other Sources"), and I am using code like:
[[NSBundle mainBundle] pathForResource:#"Auto" ofType:#"jpg"]
to get a path to the image.
I found that when running on a device (iPod Touch), the name is case-sensitive, so that if the file is "Auto" and I use "AUTO", the poath returned is "file://(null)". However on the simulator, if I use "AUTO", it works the same as if I use "Auto".
I am thinking that the fact that the simulator has such a clear difference in behavior from the device is a bug. Do the more experienced users out there think that it is, and that I should report it to Apple?
Thanks.
The iOS-Filesystem is case-sensitive, whereas the OSX-Filesystem the Simulator uses isn't.
You have to be very careful with this, I've shot myself in the foot with this more than once.
This has more to do with NS/CFBundle itself than it does with the underlying file-system:
Directly from Bundle Programming Guide: The Bundle Search Pattern:
Important: The bundle interfaces consider case when searching for resource files in the bundle directory. This case-sensitive search occurs even on file systems (such as HFS+) that are not case sensitive when it comes to file names.
You should always, always be assuming case-sensitivity. Well, perhaps a better way to express that is to say, never assume Case-insensitive-while-case-preserving (which is what HFS+ is). In the not-so-distant future, case-sensitive HFS+ could become the default format for Mac OS X. (In general, it would be preferred over the current case-preserving HFS+, but if Apple were to switch it now, there would likely be hundreds of thousands of apps that would break because of developers who made assumptions they shouldn't have. The iPhone is a clear example of the preference for case-sensitive HFS+. With no legacy programs to worry about, the iPhone has always been case-sensitive).
You are editing your code and resource names right now, so take the time to assure they match.
I am thinking that the fact that the simulator has such a clear difference in behavior from the device is a bug.
In general, this does not necessarily indicate a bug.
Do the more experienced users out there think that it is, and that I should report it to Apple?
Yes. But the bug has nothing to do with the device at all. Specifically, the bug is simply "Simulator file paths are not case-sensitive". If you can reproduce this in a "sandbox" project, do so, and submit it along with your bug report.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.