the purpose of gwts clientbundle + imageresource is to reduce the number of http request to one and to minimize the amount of transfered bytes while clientbundle creates a single jpg strip file which contains all my jpg-pics.
As example i have ten pics, clientbundle would put all these ten pics into a single jpg-strip-file
and if the app would call all these images there would be only one http request for the single-jpg-strip file.
thats what i understand.
The thing is that clientbundle is not creating a single strip file.
It creates ten cacheable files but when i am enabling caching it still does not create this single stripfile.
iam understanding something wrong what the purpose of clientbundle is?
There are two small misunderstandings in your question:
ClientBundle will only generate a sprited image for IE6/7; for all other browsers it'll use data: URLs (at least that's the default configuration) until some threshold on the size of the image and then will directly reference the image as an external one (not sprited).
ClientBundle won't generate sprited images (for IE6/7) for images with lossy compression (such as JPEGs), only for those with lossless one (such as PNG or GIF), and only if they're not animated, and only if they're not too big (threshold is controlled by a gwt.imageResource.maxBundleSize system property and defaults to 256 pixels)
In your case, I'd say that the JPEG images cross the threshold so they're not inlined as data: URLs, and because they are JPEG (i.e. with lossy compression) you don't see a sprited image generated either.
Note: there are several threshold actually for the data: URL:
one on the size of the file: https://gwt.googlesource.com/gwt/+/2.5.1/user/src/com/google/gwt/resources/rebind/context/AbstractResourceContext.java
one on the size of the data: URL (after base64-encoding): https://gwt.googlesource.com/gwt/+/2.5.1/user/src/com/google/gwt/resources/rebind/context/InlineResourceContext.java
Related
I have 1000th of PDF generated from emails containing .png (I am not owner of the generator). For some reasons, those PDF are very very slow to render with the Imaging system I am using (I am not the developer of that system and may not change it).
If I use iTextSharp and implement a IRenderListener to count the Images to be rendered, there are thousands per page (99% being 1 or 2 pixels only). But if I count the Images in the resources of the PDF, there are only a few (~tens).
I am counting the images in the resources, per page, with the code here after
var dict = pdfReader.GetPageN(currentPage)
PdfDictionary res = (PdfDictionary)PdfReader.GetPdfObject(dict.Get(PdfName.RESOURCES));
PdfDictionary xobj = (PdfDictionary)PdfReader.GetPdfObject(res.Get(PdfName.XOBJECT));
if (xobj != null)
{
foreach (PdfName name in xobj.Keys)
{
PdfObject obj = xobj.Get(name);
if ((obj.IsIndirect()))
{
PdfDictionary tg = (PdfDictionary)PdfReader.GetPdfObject(obj);
PdfName subtype = (PdfName)PdfReader.GetPdfObject(tg.Get(PdfName.SUBTYPE));
if (PdfName.IMAGE.Equals(subtype))
{
Count++
And my IRenderListener looks like this:
class ImageRenderListener : IRenderListener
{
public void RenderImage(iTextSharp.text.pdf.parser.ImageRenderInfo renderInfo)
{
PdfImageObject image = renderInfo.GetImage();
if (image == null) return;
var refObj = renderInfo.GetRef();
if (refObj == null)
Count++; // but why no ref ??
else
Count++;
}
I just started to learn about PDF specification and iTextSharp this evening, to analyze my PDF and understand what could be wrong... if I am correct, I see that many images to be rendered that are not referencing a resource (refObj == null) and that they are .png (image.streamContentType.FileExtension = "png"). So, I think those are the images making the rendering so slow...
For testing purpose, I would like to delete those images from the PDF but don't find how to proceed.
I only found code samples to remove image that are in the resources... but the images I want to delete are not :/
Is there any code sample somewhere to help me ? I did google on "iTextSharp remove object", etc... but there was nothing similar to my case :(
Let me start with the blunt observation that you have a shitty PDF.
The image you see when opening the PDF in a PDF viewer seems to be composed of several small 1- or 2-pixel images. The drawing operations to show these pixels one by one is suboptimal, no matter which imaging system you use: you are faced with a bad PDF.
In your first snippet, I see that you loop over all of the indirect objects stored in the the XObject resources of each page in search of images. You count these images, resulting in a number of Image XObjects stored in the PDF. If you add up all the Count values for all the pages, this number can be higher than the actual number of Image XObject stored in the PDF as you don't take into account that some images can be reused on different pages.
You do not count the inline images that are stored in the content streams. I'm biased. In the ISO committees for PDF, I'm on the side of the group of people saying that "inline images are evil" and "inline images should die". For now, we didn't succeed in getting rid of inline images, but we introduced some substantial limitations that should reduce the (ab)use of inline images in PDF that conform to ISO-32000-2 (the PDF 2.0 spec that is due in 2016).
You've already discovered that your PDF has inline images. Those are the images where refObj == null. They are not stored as indirect objects; they are stored inline, in the content stream of the page. As you can imagine based on my feelings towards inline images, I consider your PDF being a bad PDF for this reason (although it does conform to ISO-32000-1).
The presence of inline images is a first explanation why you have a different image count: when you loop over the indirect objects you only find part of the images. When you parse the document for images, you also find the inline images.
A second explanation could be the fact that the Image XObject are used more than once. That's the whole point of not using inline images. For instance: if you have an image that represents a logo that needs to be repeated on every page, one could use inline images. That would be a bad idea: the same image bytes would be present in the PDF as many times as there are pages. One should use an Image XObject. In this case, the image bytes of the logo are stored only once in an indirect object. There's a reference to this object from every page, so that the image bytes are stored in the document only once. In a 10-page document, you can see 10 identical images on 10 pages, but when looking inside the document, you'll find only one image that is referenced from every page.
If you remove Image XObjects by removing the indirect objects containing the image stream objects, you have to be very careful: are you sure you're not corrupting your document? Because there's a reference to the Image XObject in the content stream of your page. This reference points to an entry in the /XObjects entry of the page's /Resources. This /XObject references to the stream object with the image bytes. If you remove that indirect object without removing the references (e.g. from the content stream), you break your PDF. Some viewers will ignore those errors, but at some point in time some tool (or some body) is going to complain that your PDF is corrupt.
If you want to remove inline images, you have to parse all the content streams in your PDF: page content streams as well as Form XObject content streams. You have to rewrite all these streams and make sure all inline images are removed. That is: all objects that that start with the BI operator (Begin Image) and end with the EI operator (End Image).
That's a task for a PDF specialist who knows both iTextSharp and ISO-32000-1 inside-out. The solution to your problem probably doesn't fit into an answering window on StackOverflow.
I'm the original author of iText. From a certain point of view, iText is like a sharp knife. A sharp knife is a very good tool that can be used for many good things. However, you can also seriously cut your fingers when you're not using the knife in a correct way. I hope you'll be careful and that you're not going to create a whole series of damaged PDF files.
For instance: you assume that some of the files in the PDF are PNGs because iText suggests to store them as PNGs. However: PNG is not supported by ISO-32000-1, so your assumption that your PDF contains PNGs is wrong. I honestly worry when I see questions like yours.
On the GIMP interface one can 'Export to PNG' to save a PNG copy of your work, with layers correctly merged. In Script-Fu, however, if one does
(let*
(
(
theMergedLayer
(car (gimp-image-merge-visible-layers theImage EXPAND-AS-NECESSARY))
)
)
(file-png-save-defaults RUN-NONINTERACTIVE theImage theMergedLayer "myfile.png" "myfile.png")
)
it happens that one can not continue editing the layers separatedly.
I need to save the visible as PNG but continue editing in Script-Fu on separated layers.
Could you help?
Thanks
The way to do it - and it is the way the PNG exporting plug-in itself does it internally - is to create an internal duplicate of the image before flattening it. To do it, just call gimp-image-duplicate, and apply merge-visible-layers and file-*-save on the image copy returned by that call.
After saving, delete the newly created image with gimp-image-delete - else the duplicate will continue exiting in memory, with no displays associated (i.e. without showing on the graphical interface at all).
This copy may seem "expensive" in memory and CPU terms,but it is not at all: GIMP keeps references to the underlying pixels of the original image, until those are changed - the only change that is made, in this case, is the call do merge-layers, which then creates a new layer which would have to be created anyway.
We send bitmaps from our Silverlight client to the server to be saved, using a WCF-RIA defined service operation. Our DomainService class looks a little like this:
[EnableClientAccess()]
public class CBitmapSavingService : DomainService
{
public void SaveBitmap(string bitmapGuid, byte[] pngBytes)
{
// Save PNG on server file system
}
}
Works fine, until we get a large bitmap. Then we get a 'DomainOperationException' exception.
I suspect that we are surpassing a size limit for either the parameter or the message.
Can I reconfigure my service such that larger bitmaps can be sent from the client with WCF-RIA-Services?
I made the following change to my web.config file:
<httpRuntime requestValidationMode="2.0" maxRequestLength="6225920"/>
and it worked.
(why 6225920? Size of 2048*760 bitmap before compression, I gotta choose something)
I found the answer on another site: http://forums.silverlight.net/forums/p/186772/440463.aspx
This is only intended as a short term fix for us, because we don't really want such large bitmaps on the server. I plan to make a client side change, such that the picture type (PNG or JPEG) and quality will be changed to create an image within a defined maximum size.
This will be a little backwards from the typical approach.
I've used ExifTool for metadata manipulation before, but I really want to keep the best metadata backup I can before I make anything permanent.
What I want to do is remove the compressed image portion of a JPEG file to leave everything else intact. That's backing up EXIF, Makernotes, IPTC, XMP, etc whether at the beginning or end of the file.
What I've tried so far is to strip all metadata from a copy of the original JPEG, and use it as a basis of what bytes will be taken out of the original. After looking at the raw data, it doesn't seem like the stripped copy is contiguous in the original copy. There may be some header information still remaining in the stripped version. I don't really know. Not a good way to do it, I suppose.
Are there any markers that will absolutely tell me where the compressed JPEG image data starts and ends? I understand that JPEG files have 0xFFD8 and 0xFFD9 to mark the start and end of the image, but have come to find out that metadata is actually between those markers.
I'm using C#.
Thank you.
To do this properly you need to fully parse the JPEG/JFIF format and discard anything you don't want. Metadata is all kept in APP segments or trailers after the JPEG EOI, so presumably you will toss everything else. Full parsing of a JPEG/JFIF is not trivial, and for this I refer you to the JPEF/JFIF specification.
You can use the JpegSegmentReader class from my MetadataExtractor library to retrieve specific segments from a JPEG image.
We are seeing this when "tying" two video files together.
Example we have Ad video that is segmented and content file which is also segmented.
We create a new file which has both Ad and content segment information together. However we are seeing an issue where either the Ad content is truncated or the content starts having A/V sync issues.
Both ad and content are segmented the same way , 5 sec segmentation. however since Ads are variable length the result file may have left over segment something like:
#EXTM3U
#EXT-X-TARGETDURATION:5
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:5,
fileSequence6.ts
#EXTINF:5,
fileSequence7.ts
#EXTINF:4,
fileSequence8.ts
#EXTINF:5,
fileSequence0.ts
#EXTINF:5,
fileSequence1.ts
#EXTINF:5,
fileSequence2.ts
#EXTINF:3,
fileSequence3.ts
Is this the proper way to play 2 files one after the other without rebuffering?
should generate-variant-plist be used to a play list of 2 files?
When you have a break in the stream to switch to a commercial, ad, or alternate video source then you want to introduce the discontinuity tag before the start of the next segment, for example:
#EXTM3U
#EXT-X-TARGETDURATION:5
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:5,
movie0.ts
#EXTINF:2,
movie1.ts
#EXT-X-DISCONTINUITY
#EXTINF:5,
commercial0.ts
#EXTINF:5,
commercial1.ts
#EXTINF:3,
commercial2.ts
This gets a little more complicated if you encrypt the streams because they use progressive encryption based on the prior segments encryption state and the sequence number which come together to form an "Initialization Vector". If you break the stream you have to reset the initialization vector so that the encryption/decryption can continue uninterrupted. This is an involved process so best to just search on Initialization Vector in Apple's docs.