I have some content encoded in base64 from my server.
When I get a response and try to decode it, it does not show new lines and spaces encoded in the content.
The below code decodes properly, but when I set it as the text of the textview, no new lines or spaces are shown in content decoded.
However, saving the content decoded in sqlite and viewing in sqlite browser notepad show the text correctly.
String base64data = response.getString("data");
byte[] data = Base64.decode(base64data, Base64.DEFAULT);
String text1 = new String(data, "UTF-8");
My decoded content is like:
In typography, the point is the smallest unit of measure. It is used for measuring font size, leading, and other items on a printed page. The size of the point has varied throughout the history of printing. Since the 18th century, the point's size has varied from 0.18 to 0.4 millimeters.
1P̸2p (12 points would be just "1P̸")—traditional style
1p2 (12 points would be just "1p")—format for desktop
14pt (12 points would be "12pt" or "1pc" since it is the same as 1 pica)—format used by Cascading Style Sheets defined by the World Wide Web Consortium[3]
A typographic or printer's foot contains 72 picas or 864 points. The Metric Act of 1866 established a legal ratio of 1200 : 3937 between the foot and the meter.[4] For the survey foot used prior to 1959, this was 0.0002% more than 304.8 mm, the length of the international foot established by the 1959 International Yard and Pound Agreement.
And in textview,it is showing like this:
In typography, the point is the smallest unit of measure. It is used for measuring font size, leading, and other items on a printed page. The size of the point has varied throughout the history of printing. Since the 18th century, the point's size has varied from 0.18 to 0.4 millimeters. 1. 1P̸2p (12 points would be just "1P̸")—traditional style 2. 1p2 (12 points would be just "1p")—format for desktop 3. 14pt (12 points would be "12pt" or "1pc" since it is the same as 1 pica)—format used by Cascading Style Sheets defined by the World Wide Web Consortium[3] A typographic or printer's foot contains 72 picas or 864 points. The Metric Act of 1866 established a legal ratio of 1200 : 3937 between the foot and the meter.[4] For the survey foot used prior to 1959, this was 0.0002% more than 304.8 mm, the length of the international foot established by the 1959 International Yard and Pound Agreement.
It's hard to say what is the cause of your problem without content but there are some advices which can help you.
First, use TextView with enough size. Something like this one:
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:singleLine="false" />
I suppose you use \n symbol as line break. So when you are adding your text, replace \n symbols with System.getProperty("line.separator"). Something like this:
String text1 = new String(data, "UTF-8");
String string = text1.replace("\\\n", System.getProperty("line.separator"));
As alternative you can use SpannableString.
While decoding your base64data try to use other flags.
I guess Base64.NO_WRAP is what you want. You can also see other flags from here
byte[] data = Base64.decode(base64data, Base64.NO_WRAP);
I found a Simple but strange answer :
String base64data = response.getString("data");
byte[] data = Base64.decode(base64data,
Base64.DEFAULT);
String decoded_text= new String(data, "UTF-8");
decoded_text=decoded_text.replaceAll("[\n\r]", "WRAP");
decoded_text=decoded_text.replaceAll("WRAP","\n\r");
textview.setText(decoded_text);
Thanks
Related
I am creating a PDF document with images and text in Android using iText. Each page has an image at the top followed by some text. On the first page the image is correctly aligned to the top margin of the page, but on subsequent pages there is a gap of approximately 10 points between the top margin and the top of the image.
Here's my code:
// Create PDF document object
float pageMargin = 72;
document = new com.itextpdf.text.Document(PageSize.A4, pageMargin, pageMargin, pageMargin, pageMargin);
PdfWriter pdfWriter = PdfWriter.getInstance(document, new FileOutputStream(myFile.getAbsoluteFile()));
document.open();
PdfContentByte cb = pdfWriter.getDirectContent();
for (PicturePage picPage : picPageList)
{
// Draw a border on the page
cb.moveTo(pageMargin, pageMargin);
cb.lineTo(pageMargin, (pageHeight - pageMargin));
cb.lineTo((pageWidth - pageMargin), (pageHeight - pageMargin));
cb.lineTo((pageWidth - pageMargin), pageMargin);
cb.lineTo(pageMargin, pageMargin);
cb.stroke();
// Get an image from the file system and scale to required size
String imgFileName = picPage.getImagePath();
image = Image.getInstance(imgFileName);
float fitWidth = 400;
float fitHeight = 300;
image.scaleToFit(fitWidth, fitHeight);
image.setAlignment(Image.ALIGN_CENTER | Image.ALIGN_TOP);
document.add(image);
// Add the text to the page.
String theText = picPage.getText();
String[] arrParagraphs = theText.split("\n");
for (int i=0; i<arrParagraphs.length; i++)
{
String paragraphText = arrParagraphs[i];
Paragraph p = new Paragraph(paragraphText);
document.add(p);
}
// Start a new page
document.newPage();
}
I have tried various combinations of Image.ALIGN... and Image.TEXTWRAP but none of them remove the gap. I tried changing the order of placing the image and the border but no change. I have also tried removing the text and the border but the placement of the image is still the same.
Any ideas how to fix this?
Thanks,
Declan
I hope you won't mind if I share my opinion, but I don't like your code. There are much better ways to render images followed by a caption than the way you do it.
Now let me explain what causes the small gap to appear.
When you first create your document, the value of the leading is zero. (The leading is the distance between the baselines of two consecutive lines). This value changes as soon as you add the first object that defines a leading. In your case, this object is a Paragraph.
Although you do not define a leading explicitly, your paragraph uses a default font (Helvetica) and a default font size (12). The default leading is 1.5 times the font size (18).
Now when you go to the next page, that leading is used, introducing a small gap preceding the image. You could solve this by adding an empty Paragraph with leading 0 before triggering a new page:
document.add(new Paragraph(0));
(Add this before document.newPage();.)
However: if I were you, I'd throw away my code, and I'd add my image and my caption using a PdfPTable with a fixed width and fixed heights for the cells. You can add this table either using document.add(), or using the writeSelectedRows() method. Alternatively I could add the image at an absolute position and add the caption using a ColumnText object. There are many different ways to achieve what you want. The way you do it may work, but it's not optimal.
In order to minimize the memory usage of bitmaps, yet still try to maximize the quality of them, I would like to ask a simple question:
Is there a way for me to check if a given image file (.png file) has transparency using the API, without checking every pixel in it?
If the image doesn't have any transparency, it would be the best to use a different bitmap format that uses only the RGB values.
The problem is that Android also doesn't have a format for just the 3 colors. Only RGB_565, which they say that degrade the quality of the image and that should have dithering feature enabled.
Is there also a way to read only the RGB values and be able to show them?
For me bitmap.hasAlpha() works fine to check first if the bitmap has alpha values. Afterwards you have to run through the pixels and create a second bitmap with no alpha I would suggest.
Let's start a bit off-topic
the problem is that android also doesn't have a format for just the 3 colors . only RGB_565 , which they say that degrade the quality of the image and that should have dithering feature enabled.
The reason for that problem is not really Android specific. It's about performance while drawing images. You get the best performance if the pixeldata fits exactly in 1 32bit memory cell.
So the most obvious good pixel format is the ARGB_8888 format which uses exactly 32bit (24 for the color 8 for alpha). While drawing you don't need to do anything but to loop over the image data and each cell you read can be drawn directly. The only downside is the required memory to work with such images, both when they just sit in memory and while displaying them since the graphic hardware has to transfer more data.
The second best option is to use a format where several pixels fit into 1 cell. Using 2 pixels in 32bit you have 16bit per pixel left and one of the formats using 16bit is the 565 format. 5bit red, 6bit green, 5bit blue. While drawing this you can still work on memory cells separately and all you have to do is to split 1 cell in parts. Due to the smaller memory size required for images, drawing can sometimes be even faster than using 32bit colors. Since in the beginning of android memory was a much bigger problem they chose this format to be the default.
And the worst category of formats are those where pixels don't fit into those cells. If you take just the 3 colors you get 24 bit and those need to be distributed over 2 cells in 3 out of 4 cases. For example the second pixel would use the remaining 8 bit from the first cell & the first 16bit of the next cell. The extra work required to work with 24bit colors is so big that it is not used. And when drawing images you usually have alpha at some point anyways and if not you simply use 32bit but ignore the alpha bits.
So the 16bit approach looks ugly & the 24 bit approach does not make sense. And since the memory limitations of Android are not as tight as they were and the hardware got faster, Android has switched it's default to 32bit (explained in even more details in http://www.curious-creature.org/2010/12/08/bitmap-quality-banding-and-dithering/)
Back to your real question
is there a way for me to check if a given image file (png file) has transparency using the API , without checking every pixel in it?
I don't know. But JPEG images don't support alpha and PNG images usually have alpha. You could simply abuse the file extension to get it right in most cases.
But I would suggest you don't bother with all that and simply use ARGB_8888 and apply the nice image loading techniques detailed in the Android Training documentation about Displaying Bitmaps Efficiently.
The reason people run into memory problems is usually either that they have way more images loaded in memory than they currently display or they use giant images that can't be displayed on the small screen of a phone. And in my opinion it makes more sense to add good memory management than complicating your code to downgrade the image quality.
There is a way to check if a PNG file has transparency, or at least if it supports it:
public final static int COLOR_GREY = 0;
public final static int COLOR_TRUE = 2;
public final static int COLOR_INDEX = 3;
public final static int COLOR_GREY_ALPHA = 4;
public final static int COLOR_TRUE_ALPHA = 6;
private final static int DECODE_BUFFER_SIZE = 16 * 1024;
private final static int HEADER_DECODE_BUFFER_SIZE = 1024;
/** given an inputStream of a png file , returns true iff found that it has transparency (in its header) */
private static boolean isPngInputStreamContainTransparency(final InputStream pngInputStream) {
try {
// skip: png signature,header chunk declaration,width,height,bitDepth :
pngInputStream.skip(12 + 4 + 4 + 4 + 1);
final byte colorType = (byte) pngInputStream.read();
switch (colorType) {
case COLOR_GREY_ALPHA:
case COLOR_TRUE_ALPHA:
return true;
case COLOR_INDEX:
case COLOR_GREY:
case COLOR_TRUE:
return false;
}
return true;
} catch (final Exception e) {
}
return false;
}
Other than that, I don't know if such a thing is possible.
i've found the next links which could be helpful for checking if the png file has transparency . sadly, it's a solution only for png files . rest of the files (like webP , bmp, ...) need to have a different parser .
links:
http://www.java2s.com/Code/Java/2D-Graphics-GUI/PNGDecoder.htm
http://hg.l33tlabs.org/twl/file/tip/src/de/matthiasmann/twl/utils/PNGDecoder.java
http://www.java-gaming.org/index.php/topic,24202
Hi I am working on an android calculator apps and the now working on the manipuations. I have defined for the following:
ArrayList<Float> inputnum = new ArrayList<Float>();
float inputnum1;
float inputnum2;
and then for the operations,
case MULTIPLY:
inputnum1 = inputnum.get(0);
inputnum2 = inputnum.get(1);
inputnum.add(inputnum1 * inputnum2);
Display.setText(String.format("%.9f", inputnum.get(0)));
similar for the division one.
The muliply function and divide function works well for integers (eg 5* 4 output 20.00000000)
however, when it deals with figures with decimal places, eg 5.3 * 4, it output as 21.12000089, which is incorrect.
what is the problem?
also, how to set output to Display to remove unnecessary zero? eg
when 5*4 it only show 20 instead of 20.000000 as final answer?
when 5.3*4 = 21.12 instead of 21.12000000 as final answer?
Thanks a lot!
Just to change all the related float to double will then avoid presenting the rounding error.
If wanted to present 9 decimal places by filling up zero after the dot, eg 7.56 become 7.560000000, can use the below coding.
Display.setText(String.format("%.9f", inputnum.get(0)));
I am using a zebra RW420 in an android project and I am coding and I find that even when simply testing the printer using the ZSDK Developer Demos the printer is printing lots of extra paper when it is issued a print command. In this case I am testing out the signature capture and print demo. I do find that if I connect it to the computer and print a label created using Zebra Designer it prints the label properly with no extra paper (in fact i wouldn't mind a couple of millimeters extra in that case).
If any one knows how to save some trees here that would be great!
The code in question is:
connection.open();
ZebraPrinter printer = ZebraPrinterFactory.getInstance(connection);
GraphicsUtil g = printer.getGraphicsUtil();
Bitmap image = signatureArea.getBitmap();
g.printImage(image, 0, 0, image.getWidth(), image.getHeight(), false);
connection.close();
this works perfect for me:
Connection connection = getZebraPrinterConn();
connection.open();
ZebraPrinter printer = ZebraPrinterFactory.getInstance(connection);
// this is very important which sets automatic heigth setting for label
connection.write("! U1 JOURNAL\r\n! U1 SETFF 50 2\r\n".getBytes());
printer.printImage(new ZebraImageAndroid(bitmap), 0, 0,800, 1200, false);
connection.close();
This wont waste paper and it will print upto the availability of text/data
Assume that you have to print a receipt of width 800 and height 1200 , but it is printing a receipt of height approx. 1800 . so there is a wastage of a receipt for 600 px of white space to make use of that wastage you can use above code.
Do you have the keyword "FORM" in your CPCL label? It's usually before PRINT
This tells the printer to form feed after printing to the top-of-form setting the printer is configured to. To disable it, you can remove the FORM keyword from your format if you don't need it, or you can set the top-of-form to 0.
! U1 getvar "media.tof"
will show you what your top-of-form is currently set to
! U1 setvar "media.tof" "0"
will set it to 0, so that the FORM will feed 0 dots
I want to display two Unicode characters in TextView, but I get squares:
- ℏ (reduced Planck constant/PLANCK CONSTANT OVER TWO PI http://www.fileformat.info/info/unicode/char/210f/index.htm)
- ℞ (PRESCRIPTION TAKE http://www.fileformat.info/info/unicode/char/211e/index.htm)
I know that not all Unicode characters are supported by default Android font, but reduced "h-bar" is Latin character and it's one of the fundamental physical constants. Can anyone confirm that I making everything right? And if, how to solve this problem (third-part font is the only solution)?
view = new TextView(this);
int[] codePoint = { 0x210f, 0x211e };
String hhh = new String(codePoint, 0, codePoint.length);
view.setText(hhh);
According to the character set page the Droid fonts don't support U+210F (ℏ), but they do support U+0127 (ħ), so you might consider using an italic font and U+0127 instead.
add font containing characters to /system/fonts,
modify /system/etc/fallback_fonts.xml so android finds font then
reboot.
Everything should be working now