I had a scaling issue on printing an SVG file that is exported from Inkscape. It turns out that the issue is caused by wrong/incompatible printer settings.
Is there a way to propose the printer settings from within an SVG file where the application must take in consideration upon printing that file?
In short: No, it's not possible.
First of all, an SVG file is not intended for print. It's a simple vector file format used for web graphics. It can't even have a color profile or multiple pages.
Even if we were talking about a PDF (which is intended for print) it's not possible to force printer settings like paper format, orientation, fit to printer margins/actual size, grayscale/color, resolution etc.
In this case, it might sound like a good idea to be able to do that, but seen from the user's point of view it would be very annoying if documents didn't behave in the same way and constantly tried to override the user's preferred printer settings.
Furthermore, different printers could have different settings available. I'm not sure, but I don't think there is a global standard for this. There could be manufacturers who uses their own standard.
I do understand why you want this. I often send designs for approval to my clients and they tell me everything looks kinda small - they are unaware of the fit to printer margins/actual size issue, but I can't control their printer, so I have to instruct them to print at actual size/100%.
Related
I'm aware of the existence of DDS files which allow programming of display graphics on the as/400, but is there another way?
Specifically, what I want to do is manipulate the terminal buffer directly to be able to display anything else than just text.
For example, the terminal looks like that:
Let's say, in memory, there would be a two dimensional char array: text[20][80] for the text menu and lower than that, there would be a pixel buffer array of size [200][800].
Is there a way to access either of those arrays directly?
I would like to be able to create a displayable menu entirely in C without the need of a display file and also display other kind of graphics (images) directly in the pixel buffer.
Is there a way to access either of those arrays directly?
That's easy enough, though a "display file" that has no formatted fields will still be needed. The 'file' will be the connection between the program and the physical device (or the emulator). You can define a single large area that contains whatever "text" you want your program to put into it. This can even include display field attributes that delimit input areas.
For the most control, the DDS USRDFN keyword is appropriate. But for simple stuff like lists of menu items, almost any large text field can be output to.
Outputting simple text is easy. For detailed stuff like USRDFN formatting, detailed understanding of the 5250 protocol is needed.
One kind of alternative would be to use User Interface Manager (UIM) APIs to update a PANEL's "text area" (:TEXT) via its USREXIT= application program. The UIM handles everything as far as any "display file" definition and actual I/O goes. The UIM can be thought of as a HTML interface for 5250 and uses a very similar markup language to define PANELs.
Another alternative is the Dynamic Screen Manager (DSM) APIs. These give much finer control than the UIM or DDS methods (though DDS USRDFN gets very close). But as with USRDFN, actual device control will require 5250 protocol knowledge.
...and also display other kind of graphics (images) directly in the
pixel buffer.
There is no "pixel buffer" for 5250 nor even 'pixels'. It's a character-based protocol, like telnet. If you're going for images or 'pixels', you're into browser interfaces, or perhaps Java and NAWT, or X-windows, etc.
Now, granted that with TCP/IP and sockets, you can do essentially anything that you're able to program. Whatever you can figure out how to do, including downloading/installing 3rd-party code libraries, you can do -- within the network restrictions surrounding your server. But it is in fact a server, so GUI kinds of apps generally shouldn't run on it. That's the same as for almost all types of servers. Code the GUI on the client system rather than the server. But you can do it if you really want to.
I'm not sure why you'd want to do this...
Now-a-days, it'd be much easier to simply generate your output as HTML and serve it up via the integrated apache web server.
But if you really want to do graphics via 5250, it can be done...theoretically at least. In 20+ years on the platform, I've never seen it.
But way back when (1994?), IBM added support for Graphical Data Display Manager (GDDM) and Presentation Graphics APIs into OS/400. "GDDM is a means of
displaying, printing, or plotting pictures. Presentation Graphics routines are a
means of displaying, printing, or plotting business charts."
The support is still in the OS. However, client side support is NOT available in IBM i Access for Windows or the most recently released client, IBM Access Client Solutions (ACS). It appears that the standalone IBM Personal Communications product may support GDDM.
For complete control of the character buffer, take a look at the Dynamic Screen Manager (DSM) APIs. The DSM APIs are "a set of screen I/O interfaces that provide a dynamic way to create and manage screens for the Integrated Language Environment® (ILE) high-level languages. Because the DSM interfaces are bindable, they are accessible to ILE programs only."
There is a way to do it in ILE C/C++. This was very fun to investigate since I haven't tried it myself.
The only documentation on it (page 183+) I could find is from 5.1, but you are able to cross reference the functions used to this 7.3 manual (possibly page vii/7) to see if they're still used the same.
Hope this helped!
how should we set the xml layout in android that supports different screen sizes.
I tried using wrap content and match parent but its not working properly. Please guide me for this.
Thanks in advance.
The comment about, Supporting Multiple Screens is defiantly a good starting place! By default your xml does support different screen sizes.
Although the system performs scaling and resizing to make your application work on different screens, you should make the effort to optimize your application for different screen sizes and densities. In doing so, you maximize the user experience for all devices and your users believe that your application was actually designed for their devices—rather than simply stretched to fit the screen on their devices.
However, like it says you need to optimize it. This refers to images or a completely different xml per screen size/orientation. Does this help any?
If you need something a little more specific to your situation you'll need to provide more information.
Are there any open source scripts that will allow you to enter a website url and it will generate a color palette based on your site? I would prefer something that ran on a typical LAMP stack. I've been able to find many websites that offer the functionality as a service but no downloadable scripts...
Update: I'm looking for the palette to contain the hex color values
Presumably easiest would be to render the page and count the pixels of different colors from a screenshot, because otherwise you can't tell which colors from the CSS file actually cover large areas. It's unlikely you could script this easily from command line but if you have a windowing environment, writing such a program wouldn't be too complicated. If you use QT, you can load the page into a QWebView, use QPixmap.grabWindow to get the pixels, convert it to QImage and then loop through the pixels counting them.
When converting the web page to an image, a big point to have in mind is that a user could send it to a malicious website to take advantage of a security problem in whatever rendering engine you are using, and even take over the server. Make sure to at least disable JavaScript and Flash, even though that will make some websites look different from normal. Otherwise it's far too easy to get the program stuck in an infinite loop even if nothing else.
I have an SWF file with only vector illustrations in it (no bitmaps). Is there a way to improve colour consistency across different monitors?
Colour management is a very complex topic and the more I read about it the more confused I become. There's this thing called ICC profiles which are supposed to convert colours into device independent color spaces, but of what use is that?
ICC profiles provides a way to map the colors that your monitor thinks it's showing (the bitmap/image, or other graphics) to what it is actually outputting on the panel. Using software that supports these profiles you can get more consistent colors.
The basic flow is this:
A program reads the graphics file
The program uses the icc profile to compensate for your monitors inadequacies
When you change monitor, you change the icc-profile to match the new monitor
When you print, you use a different icc-profile suitable for the printer to compensate for the printers inadequacies
This is meant to make sure that the colors on screen match the printed paper and is generally not something that scales beyond artsy stuff.
If you want consistency among your own monitors you would "just" have to calibrate them and configure the profiles for your monitors. I don't know how to do this, but my guess is that Adobe has pretty good docs about it.
If you want something like consistent colors on say a flash game across different users, I don't think that is possible. In any case it would be the clients job to manage the ICC-profile and the flashplayers job to support the compensation.
In any case, the part about adjusting the monitor settings before doing the calibration is because this changes the color reproduction of the display, so if you change the settings you will have to re-calibrate the display.
The problem is you have no control over your user's monitor (type, make, age, adjustment).
ICC profiles are designed to interpret between a real-world device (like a camera, monitor or printer) and an independent working colour space (see here for an explanation).
Flash 10 "supports ICC-profiles" only in the sense that you can specify whether or not flash should adjust it's colours according to the local ICC profile (chosen by the user to suit their monitor). So the most you can do is set stage.colorCorrection = ColorCorrection.ON; (and it won't work for Unix or Linux).
Otherwise, you could consider making the colours shown in your SWF file to be user-configurable: they can then adjust things to their own liking - perhaps via some form of colour-calibration.
I'm currently designing my first ever GUI for Windows. I'm using MFC and Visual Studio 2008. The monitor I have been designing my program on has 1680x1050 native resolution. If I compile and send my program to one of my coworkers to run on their computer (generally a laptop running at 1024x768), my program will not fit on their screen.
I have been trying to read up on how to design an MFC application so that it will run on all resolutions, but I keep finding misleading information. Everywhere I look it seems that DLUs are supposed to resize your application for you, and that the only time you should run into problems is when you have an actual bitmap whose resolution you need to worry about. But if this is the case, why will my program no longer fit on my screen when I set my monitor to a lower resolution? Instead of my program "shrinking" to take up the same amount of screen real estate that it uses at 1680x1050, it gets huge and grainy.
The "obvious" solution here is to set my resolution to 1024x768 and redesign my program to fit on the screen. Except that I've already squished everything on my dialogs as much as possible to try and get my program to fit on screen running at 1024x768. My dialog fonts are set to Microsoft Sans Serif 8 but still appear huge (much larger than 8 points) when running at 1024x768.
I know there HAS to be a way to make my program keep the same scaling... right? Or is this the wrong way to approach the problem? What is the correct/standard way to go about designing an MFC program so that it can run on many resolutions, say 800x600 and up?
I assume your application GUI is dialog based (the main window is a dialog)?
In that case you have a problem, because, as you discovered, MFC has no support for resizing a dialog correctly. Your options are:
Redesign your GUI to use a SDI or MDI GUI.
Use a dialog resize extension. There are many available, for some very good suggestions see this question. Another options are this one and this one.
Don't use MFC. wxWidgets has much better support for dialog resizing.
MFC is only a thin wrapper over the Windows API. They both make an assumption which is hardly ever true: if you have a higher resolution screen, you'll adjust the DPI or font size in Windows to get larger characters. Most of the time, a larger screen size means a larger physical monitor, or a laptop where you want to squeeze as much information into a small screen as possible; people value more information over greater detail. Thus the assumption fails.
If you can't squeeze your entire UI into the smallest size screen you need to support, you'll have to find another way to make it smaller. Without knowing anything about your UI, I might suggest using tabs to group the controls into pages.
I've had good luck making my windows resizable, so that people with larger screens can see more information at once. You need to do this the hard way, responding to the WM_SIZE message to the window and deciding which controls should be made larger and which ones should just move.
There is no automatic way to resize the content of your dialogs when resolution changes. So, you need to set some boundaries.
Option 1.
If you are developing your app for customers, pick one minimum resolution (like 1024x7678), redesign you dialogs so that everything fits. Maybe break up some into several, or use tab strip control.
Option 2.
Create separate dialog forms for each resolution you'd like to support, but use the same class to handle it. At runtime detect resolution and use the appropriate form.
Option 3.
Write your own resizing functionality, so that user could adjust the size of your dialogs to his liking.