I experience some unexpected behavior from my camera. Using VIDIOC_ENUM_FMT for V4L2_BUF_TYPE_VIDEO_CAPTURE I receive two supported formats: MJPG and YUYV. But when I try (actually WebRTC DeviceInfoLinux::FillCapabilities() tries for me) to list supported formats with VIDIOC_TRY_FMT, it happily reports much more:
supported MJPG 640x480x30
supported MJPG 1280x720x15
supported I420 640x480x30
supported I420 1280x720x15
supported YUY2 160x120x30
supported YUY2 320x240x30
supported YUY2 640x480x30
supported YUY2 1280x720x15
supported UYVY 640x480x30
supported UYVY 1280x720x15
Are some of these formats emulated by the video driver?
Digging deeper into the answer produced by VIDIOC_TRY_FMT reveals an interesting fact that is completely ignored by DeviceInfoLinux: the answer pixformat is not always equal to the query pixformat (also, answer width and height are not equal to query width and height). Actually, only MJPG and YUYV appear as results, so IMHO this is a bug of WebRTC to show these formats as supported: they check that the sizes are equal, but not the pixformat.
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 am trying to migrate from PDFBox 1.8.8 to 2.0.1 but what is the equivalent to use for TYPE_BYTE_INDEXED in PDFBox 2.0.x ?
Rendering to TYPE_INDEXED was removed in 2014 due to alleged poor performance, see here.
...because it prevents the user from passing in arbitrary types which are
known to cause poor performance e.g. TYPE_INT_BGR, well actually any
type other than TYPE_BYTE_BINARY, TYPE_BYTE_GRAY, TYPE_INT_RGB or
TYPE_INT_ARGB.
The solution would be to render to RGB and then convert to whatever unsupported type you want.
I have a XML String with in the <xml> tags in a .jsp file and I am trying to load that xml using xmldoc.Load(document.all("Info")) and it is giving an error
Invalid procedure call or argument
but everything works in Ie9. When I inspect the document.all("Info") it says
Object UnknownHTMLElement in IE 10 and Object in IE9.
here is the code snippet which I used
var xmldoc=new ActiveXObject("MSXML2.DOMDocument.3.0");
boolXMLLoaded=xmldoc.load (document.all("UserInfo"))
<xml id=UserInfo>`
<?xml version='1.0'?><RESPONSES UserName=" DOUGLAS ................
</xml>
Any help is greatly appreciated..
The reason your code doesn't work in newer IE versions is because you're using obsolete (very very obsolete) code. You need to update to modern web standards if you expect modern browsers (including IE10) to work.
Two issues are obvious immediately:
document.all has been deprecated for years; you shouldn't be using it -- it is non-standard and only still exists to allow backward-compatibility with ancient versions of IE (eg IE5). Modern IE versions won't like it, and it definitely doesn't work on browsers other an IE.
In most cases, if you're trying to reference an element by ID (as in this case), you should use document.getElementById() instead.
Further info from Mozilla Developer Network.
new ActiveXObject("MSXML2.DOMDocument.3.0") is also non-standard and deprecated, and also shouldn't be used in modern browsers. Again, it is IE-specific, and was replaced from IE7 onward with the web standards alternative.
You should replace it with document.implementation.createHTMLDocument();. See also the anwsers here.
If you need to support IE6 or earlier then you can detect whether the browser supports the standard syntax and provide a fall back to the old ActiveX control only for old IE versions.
Given that the tiny bit of code you've shown us is using two obvious and well known features that are so badly out-of-date, I would expect to see more problems of a similar nature if we were to see more of your code. Because of this, I would recommend posting some of your code on SO's sister site https://codereview.stackexchange.com/ to get some additional feedback on how you can improve it.
Hope that helps.
var xmldoc= new ActiveXObject("Microsoft.XMLDOM");
replace this in place of
var xmldoc=new ActiveXObject("MSXML2.DOMDocument.3.0");
and try it again
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
}
In Safari & Webkit, using only border-radius seems to work without adding the prefix -webkit- to it. Is it okay to leave -webkit- prefix for border-radius?
You miss the point of validation. You validate to avoid errors! These include: unsafe browser extensions, hacks, ie-hacks, and actual errors. By no means should you validate to make your code less cross-browser functional.
You should be aware there are such things as expected errors, and even valid code works with those. Browser extensions like -moz-, -webkit-, and -o- are expected errors. All browsers are designed to drop unknown rules. This is how CSS allows for backwards compatibility. A CSS2 supporting browser will drop the CSS3 border-radius rule. Being valid or invalid doesn't have anything to do with it, and by no means will any browser just break because of it (fortunately for us the idea of turning CSS into XML was squashed and never saw the light of day). Opera will drop -moz- rules and Firefox will drop -o- rules, this is not a error. This is expected behavior:
An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS. Thus typical CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors. However, because the initial dash or underscore is part of the grammar, CSS 2.1 implementers should always be able to use a CSS-conforming parser, whether or not they support any vendor-specific extensions.
The w3c even defines how to write these "Vendor-specific extensions". The following are the current extensions well known ones:
-ms-, mso- Microsoft
-moz- Mozilla
-o-, -xv- Opera Software
-webkit- Apple
-khtml- KDE
There are also some you might have never even heard of:
-atsc- Advanced Television Standards Committee
-wap- The WAP Forum
Browsers implement draft-stage or partial implementations (ie. browser supports X, Y but not Z) of CSS rules, as extensions. This way they prevent any change in the spec from breaking previous versions of the browser. There have been cases where browsers have gone gun happy and implemented them as non-extensions, and the usual result has always been said browser has shot themselves in the foot, things like: "browser XXX version YYY has bad implementation of [...]". Most notably IE stands at the no.1 spot on this, but other browsers too have successfully managed to shoot themselves in the foot. When a draft becomes standard and the browser fully (or sufficiently) implements the spec, a rule is created with out the -xxx- prefix.
In recent years, all major browsers have adopted this as a de facto standard.
How and when to use -xxx- browser extensions? As usual the best practice is to design using only standards compliant code in the most advanced browser you have at your disposal then add all the safe extensions. Out of the extensions use the ones based on w3c standards or current working drafts. Don't use dropped standards/drafts or browser wannabe-standards (ie. some of the old Firefox ones). Also avoid any sort of tinkering rules unless it has a stable fallback.
In the case of the border-radius rule you have a stable fallback.
How to keep both form and function? In my opinion most people are not bothered by the "ohmygosh it's not valid" but rather the fact they are forced to write multiple rules for the same line. A simple solution to this is to use a template system. There are quite a few out there for CSS, as the problem of keeping your code DRY is a persistent one.
The are many many many different implementations out there. The basic idea though is to solve the problem using a mixin (ie. function):
=border-radius(!radius)
-moz-border-radius= !radius;
-webkit-border-radius= !radius;
-khtml-border-radius= !radius;
border-radius= !radius;
We can now write this everywhere:
.stuff
+border-radius(15px);
This code is much more flexible then just writing border-radius: 15px and hoping for the best. It's also maintainable (what no element should have more then 10px border radius? no problem).
You may run into css validation errors by doing so. - prefixed properties are regarded as optional extenstions, and thus have a lesser likelihood of causing problems.
I would suggest you keep the -webkit just incase, some browsers (IE) don't play nice when HTML/CSS don't validate. This is known as quirks mode.
border-radius supports safari 5 and later. -webkit-border-radius supports safari 3 and later.
So if you wish to have support for safari 3+ you have to use -webkit-border-radius