I'm creating a small size Flex movies which contains two line charts, at the moment the size of the release build swf is 343KB, which is too large for our needs.
I've tried changing the loading of the SWC file to Runtime Shared Libraries, but I found that this removed the text of the charts (the text for the x and y axis). Why would the text be removed when the Framework linkage is set as a Runtime shared library?
Thanks
Stephen
that is indeed very strange. Here are some things I can think that might cause this issue:
1.) Embedded Font issue: Is the text embedded, or is the font the text is rendered in being embedded? Check to make sure - weird things can happen when fonts are embedded in one swf and loaded into another. Try un-embedding the font and see if that fixes things. If that fixes the issue, you might need to embed it in both swfs to make it work, or try various combination of embedding in one or the other.
2.) Some weird CSS styles: are you styling the text using CSS? If so, make sure the styling is being set correctly, or that styles in your main app aren't clobbering the styles used by your RSL.
3.) The actual text data: put a few trace statements (or alert windows) into your RSL and make sure the text is actually being set. It's possible that those labels aren't correctly receiving their data. I realize this is somewhat automated in Charting, but some of the axes require label data from dataproviders and I thought you might be doing that.
4.) The axes: make sure the axes are still being set correctly in your RSL, and that nothing in your main app is clobbering the type of axes being set on the chart.
I hope this helps get you started - in general I'd just fire up ye ol' debugger and start working backwards to figure out at what point the text disappears. This will help you narrow the issue down to something more fixable.
Related
I have been building small "proof of principle" programs to learn about GTK3, and now that GTK4 has limited availability, I have been attempting to learn about this version as well. In attempting to migrate to GTK4, I took a program I wrote for GTK3 that displays two progress bars with different attributes using CSS providers and rebuilt it under GTK4. When I ran the GTK4 version of the program, the CSS overrides in the program are ignored unless I introduce the CSS provider context to the display level for one of the progress bars. But that then results in having both progress bars exhibiting the same behavior instead of having unique behavior for each progress bar. Just as a further test, I added CSS providers and context for a label widget and that override worked. So some CSS overrides in GTK4 work as before, but some do not. It is as though some CSS provider overrides are ignored at the display level. Reviewing documentation about priorities (e.g. GTK_STYLE_PROVIDER_PRIORITY_APPLICATION) and testing out various priority constants did not make a difference.
Displaying the content of the code would be too long in this narrative, so I have uploaded the GTK3 and GTK4 versions of the code to my Github repositories along with a "pdf" file visually illustrating the different behavior between GTK3 and GTK4. If you want to review and test out the code yourself, the link is:
https://github.com/cschuls/GTK4_Mystery
I would suppose that widget-specific CSS customization could be added at the display level with an "id#" attribute, but that seems like that would just be adding unnecessary complexity when this practice works fine with GTK3. Thanks in advance for any answers and suggestions.
Additional comment.
Experimenting with various scenarios, I came up with a work-around that provides the desired result of having distinct style properties applied to each progress bar widget. For those widgets, I added their respective CSS provider data to the display style context instead of attempting to add the CSS provider to each widget's context. If you wish to view this work-around, I added a "work-around" folder with the source code to my Github repository.
This provides a decent solution to this problem, but it does not answer my underlying question as to why the CSS provider information for each progress bar widget is not enacted upon during the application's execution; whereas, CSS provider information associated with widgets such as labels and buttons do behave as they did with GTK3. If anyone can answer my core question, I would be very happy.
Regards,
Craig
I'm new to Flash and I trying to do something as following:
I need the ability run several layers of animation (image sequences) in a single file (ex. SWF) which will be loaded and accessed dynamically by Flex - I need to change the content (image sequence) in runtime in order to customize my animation.
What would be the best approach in this case?
Is it the correct direction?
Should I consider creating a SWF for each animation and load it dynamically into my layered SWF?
When you say you need to adjust the image sequence, do you mean customise the order of individual frames, or simply select between a selection of set sequences?
If it's the former, the answer will be a bit more in-depth, if it's the latter and there aren't too many you're probably best off exporting as SWFs, or even as a video file to compress them, then loading them in dynamically. If they're small enough not to add significant weight to your SWF, you could export them as MovieClips in a SWC and create instances of them directly in the code without having to load them in.
Hope this helps (sorry if any of the above is confusing!) - could you give a bit more detail on what you're trying to achieve?
My Flex 3 app prints pages just fine from browsers on Windows using FlexPrintJob (not the browser print function). However, on OSX, the left and top margins show up larger and the page gets pushed off the right and bottom. Basically, the scaling is screwed up, and I can't see any way to adjust the margins in code.
Has anyone seen this discrepancy in Flex printing between Windows and OSX? Are there any known workarounds? I've searched all over and I can't find any good info on this (other than 12 unresolved printing bugs in the Adobe Jira DB).
And please don't say "don't print in Flex". I know Flex sucks at printing, but I have to use it. Thanks!
Edit:
PDF Generation is one route and while its a valid solution for some folks, I need to print directly. I'd like to see stuff like using regular Flash PrintJob, monkeypatches to FlexPrintJob, or just ways I can format my DisplayObjects before sending them to FlexPrintJob. None of the scaling options in FlexPrintJob work. My Flex Component is at 1.0 scale. I'm not sure what else I can do except for mess around with regular PrintJob. I'm putting a bounty on this for answers in this domain.
Switch to PDF generation. There are two ways to do this without having to purchase server-side licenses:
Use our library of Flex components - clear.swc, a part of open source Clear Toolkit available on Sourceforge. This process is described in Ch. 11 of the book Enterprise Development with Flex currently available as rough cuts on safaribooksonline.com
Use open-source library alivePDF.
Don't print by Flex PrintJob :)
I am working on an ASP.Net web application that must print dynamically created labels on standard Avery-style label sheets (one particular size, so only one overall layout). The labels have a variable number of lines (3-6) and may contain either lines of text or a graphic barcode image.
Our first cut, that I inherited, used monospaced fonts to reduce the formatting issues, but that did not allow enough text to the fit on the labels and the customer was dissatisfied. Basically it was formatted text.
My next version used TABLEs, DIVs, CSS, and a bit of JavaScript calculations to format the labels using proportional fonts. It still required a bit of tweaking (the user had to set their print margins correctly and turn off the print headers and footers), but it seemed to work.
However, it seems that there are some variations on how different printers render the text (WYS ain't WYG), so even though we tested on different browsers using at least two different printers (an inkjet and a laser printer), some user's labels don't line up. Slight margin variations can be adjusted by adjusting the margins on the page setup dialog, but the harder problem is that the inter-label spacing can be off by a tiny fraction of an inch, so that if the first label is pretty well centered, by the end of the page the label text and images have crawled off the top or bottom of the labels.
We are about to the point of switching to generating Word, Excel, or PDF output which is going to take quite a bit of development time and possible add extra steps in the printing process.
So, does anyone have any suggestions on how to do an HTML/CSS layout that will precisely render on different types of printers? I don't really care if the line/word breaks are a bit different, but I need to be able to predictably position the upper left corners of each label area.
Right now the labels flow down the page in a table and we have been tweaking the box model of the cells and internal DIVs to make them a uniform height. I suspect that using absolute positioning of each element may be the best answer, but that is going to be tricky as well due to the ASP.Net generation of the label elements. If I knew for sure that would work, I would rather try it than throw away everything we have to go to a different generation method.
Slight Update:
Right now I'm doing some tests with absolute positioning - setting only the top and left coordinate of a containing block element. So far there are minor variations on the offset onto the page (margins, paper alignment, etc.), but all browsers and printers tested put the elements in exactly the right spots relative to each other. I appreciate the PDF tips, but does anyone know of additional "gotchas" on using absolute positioning this way?
Update:
For the record, I rewrote the label printing portion using iTextSharp and it works perfectly - definitely the way to do this in the future...
Forget HTML and make a PDF. HTML printing is extremely variable - not just across browsers but across different versions of the same browser. PDF is a lot easier.
Even if you get it exactly right with one browser / font setup / printer / phase of the moon, it will be the most fragile thing you've ever had to maintain. No matter how long you think it will take to make a PDF (and it's not really that hard as there are some free libraries out there), HTML will ultimately take a lot more of your time. PDF readers are widely deployed and print more consistently than even Word files.
The web is not a format that is guaranteed to get consistent print results. Given the standard support for label printing with MS Word, and the relative ease of automation and generation, I would strongly recommend going that route.
I'm not aware of ANY method to get percise printing across all types of browsers, operating systems, and printers when using web content.
"precisely" and "printing" aren't two words that really work together that well. I did an OCR/OMR application a year or so ago, and even when building a PDF I saw significant differences between different print drivers and such. Because of that, my gut is to tell you that you might not have 100% success.
If CSS and layout issues don't work that well for you, you might need to resort to building the labels as images using GDI+ -- at least that way you can use GetFontMetrics() and such.
Good luck!
I had a similiar issue and the answer is you can't do it. Instead, I generated a PDF file in realtime using iTextSharp and passed that to the response.
Using SQL Server Reporting Services, I generate a PDF to send to the printer, but it can be seen as HTML on the screen using the control you can include in your web pages. There are RDLC files that are available on the internet to print to various Avery formats.
I rewrote the SharpPDFLabel code that was mentioned back in 2011 this week as I needed it to be a lot more flexible (and to work with the current iTextSharp library).
You can get it here:
https://github.com/finalcut/SharpPDFLabel
I added the ability to specify the contents of each individual label if you want (or to continue creating a sheet of identical labels too). By extending the LabelDefinition class you can specify the layout of your labels pretty easily.
I also struggled with the HTML/CSS approach due to the inconsistent printing behaviour across browsers.
I created a C# library to produce Avery Labels from ASP.NET which I hope you might find useful:
https://github.com/wheelibin/SharpPDFLabel#readme
You can add images and text to the labels, and it's easy to define more labels types.
(I use it for barcode labels, the barcode is generated as an image and then added to the label using this library.)
Cheers
Add a few options to your app that let users adjust spacing for their particular configuration. You could include this right on the label if you want, and style it away via media selectors, but you'll probably want to persist them somewhere, too.
Flash is also good method to push a printable like a label albeit a little more complex to implement and maintain. In most cases it displays much quicker than a PDF and you can embed it into the design of the page and simply add a "Print" button within the flash.
I did this several years ago when we were using HTML and PDF to generate confirmation receipts. HTML is "ok" but is at the mercy of the end users web browser so we quickly dumped that method. PDF's are good as long as they have a PDF reader, which to our surprise a lot of our customers did not. So that was dumped as well after we switched to a FLASH version using a simple flash movie that included a few dynamic text areas and a "print" button. I communicated the data between the page and flash using a few flash vars. You can also use web service.
When I need something more than just simple text I use the free community edition of the PDF Generator component from DynamicPDF.com. It works great and is very quick.
I just went through the same thing. Ended up switching and making a short little JSF app (running on Glassfish) that uses JasperReports to print directly to the lable printer. Push button, instant label at the printer, don't even have to view it on-screen if you don't want to since Jasper can directly output to printer (as well as PDF in browser).
Usually Flash and Flex applications are embedded on in HTML using either a combination of object and embed tags, or more commonly using JavaScript. However, if you link directly to a SWF file it will open in the browser window and without looking in the address bar you can't tell that it wasn't embedded in HTML with the size set to 100% width and height.
Considering the overhead of the HTML, CSS and JavaScript needed to embed a Flash or Flex application filling 100% of the browser window, what are the downsides of linking directly to the SWF file instead? What are the upsides?
I can think of one upside and three downsides: you don't need the 100+ lines of HTML, JavaScript and CSS that are otherwise required, but you have no plugin detection, no version checking and you lose your best SEO option (progressive enhancement).
Update don't get hung up on the 100+ lines, I simply mean that the the amount of code needed to embed a SWF is quite a lot (and I mean including libraries like SWFObject), and it's just for displaying the SWF, which can be done without a single line by linking to it directly.
Upsides for linking directly to SWF file:
Faster access
You know it's a flash movie even before you click on the link
Skipping the html & js files (You won't use CSS to display 100% flash movie anyway)
Downsides:
You have little control on movie defaults.
You can't use custom background colors, transparency etc.
You can't use flashVars to send data to the movie from the HTML
Can't use fscommand from the movie to the page
Movie proportions are never the same as the user's window's aspect ratio
You can't compensate for browser incompetability (The next new browser comes out and you're in trouble)
No SEO
No page title, bad if you want people to bookmark properly.
No plugin information, download links etc.
If your SWF connects to external data sources, you might have cross domain problems.
Renaming the SWF file will also rename the link. Bad for versioning.
In short, for a complicated application - always use the HTML. For a simple animation movie you can go either way.
You also lose external control of the SWF. When it's embedded in HTML you can use javascript to communicate with the SWF. If the SWF is loaded directly that may not be possible.
Your 100+ lines quote seems pretty high to me. The HTML that FlashDevelop generates for embedding a SWF is only around 35 lines, with an include of a single swfobject.js file. You shouldn't need to touch the js file, and at the most would only have to tweak the HTML in very minor ways to get it to do what you want.
In my experience not all browsers handle this properly. I'm not really sure why (or which browsers) but I've mistakenly sent links like this to clients on occasion and they've often come back confused. I suspect their browser prompts them to download the file instead of displaying it properly.
One upside I can think of is being able to specify GET parameters in the direct URL to the SWF, which will then be available in the Flash app (via Application.application.parameters in Flex, not sure how you'd access them in Flash CS3). This can of course be achieved by other means as well if you have an HTML wrapper but this way it's less work.
Why would you need 100+ lines of code? Using something like swfobject reduces this amout quite some (and generally you don't want to do plugin detection, etc. by hand anyway).
More advantages:
Light weight look cuz you can get rid of the header with all the tool bars that seem to accumulate there and even the scroll bar is not needed. This enhances the impact when you are trying to show a lot of action in a short flash.
The biggie: you get it in a window that you can drag larger or smaller and make the movie larger and smaller. The player will resize the movie to fill the window you have. This is great for things like group photos where everyone wants to enlarge to find themselves and their friends. I've done this for a one frame Flash production!
Downsides:
As with popups in general, if you are asking for multiple ones from the same site, and you want different size popups, the browsers tend to simply override the size you ask for in window.open and reuse whatever is up. You need to close any open popup so the window.open will do a fresh create. It gets complicated, and I have not been able to get it to work across pages in a website. Anyone who has done this successfully, pls post how!
Adobe should be ashamed of themselves with the standard embed, which defeats the puprose of convention over configuration. Check ^swfobject (as mentioned above) or swfin