I am working on creating a DXF file which results in a ellipse for Autocad 2012.
ellipse.dxf file is as follows.
0
SECTION
2
ENTITIES
0
ELLIPSE
5
2C
100
AcDbEntity
8
0
62
2
100
AcDbEllipse
10
2.456341489793
20
1.0357141474129
30
0.0
11
3.39798382641241
21
0.0
31
0.0
210
0.0
220
0.0
230
1.0
40
0.1413778446865976
41
0.0
42
6.283185307179586
0
ENDSEC
0
EOF
and the autocad is showing the following error :"Autocad 2012 undefined group code 10 for object on line 18".
Its getting hard for me to figure what is wrong with the group code 10 as it represents the x-axis first point. If I delete the group code 10 and 2.456341489793 it is than showing the same for groupcode 20.
Your group codes are not formatted correctly. All group codes are 3 characters in length. If there are not 3 digits in your group code, then the code must have enough leading spaces to make up 3 characters. As an example: group code 10 must actually be written to the dxf file as " 10" (without the quotes).
The leading spaces are a key part of the group code. This helps to differentiate between a group code and data.
So if group code 10 has a value of 10, the leading spaces in the group code allow the dxf interpreter to differentiate between them.
EDIT
Corrected group code length from 4 to 3.
You created a minimal DXF with only the ENTITIES sections. When you open this DXF file in AutoCAD, AutoCAD expects a DXF R12 file, and DXF R12 does not support the ELLIPSE entity, which was introduced with DXF R13/14. AutoCAD should better complain about the ELLIPSE entity and not about the group code 10. This minimal DXF with just a CIRCLE entity works:
0
SECTION
2
ENTITIES
0
CIRCLE
8
Layer_is_a_required_tag
10
0.0
20
0.0
40
1.5
0
ENDSEC
0
EOF
#Stewbob: Leading spaces to group codes are a convention by AutoCAD but not mandatory
Related
I'm working on printing 1x3" label to a Zebra ZQ320 using C# and Xamarin Forms. Below is the code that I'm using to setup the print job and then generate the label. This code currently works great if I'm manually aligning the label properly and then printing, except for after the print job is complete, I have to press the feed button on the printer to feed to the tear off line on the label (which over time makes the label unaligned).
! UTILITIES
BAR-SENSE
SET-TOF 0
IN-MILLIMETERS
SETFF 0 2.5
PRINT
! 0 210 210 210 1
TEXT 7 0 0 15 {_location}
TEXT 7 0 450 15 {_minMax}
CENTER
TEXT 4 0 0 0 {_company}
TEXT 7 0 0 50 {_description}
BARCODE 128 2 2 40 0 85 {_materialNumber}
TEXT 7 0 0 130 {_materialNumber}
FORM
PRINT
So, I have two questions:
Is there something I can modify about this print job to force the auto-alignment to the tear off line?
Is there a way to auto-align to the next feed line at the beginning of the print job? I would not want it to auto-align if it's currently at a good position.
I am using the following as reference for what commands are available: Zebra CPCL Manual
The PDF which I signed with append mode is exported from Office Word 2016.
Here is my file : word.pdf
And I got this error message:
com.itextpdf.kernel.PdfException: Append mode requires a document without errors, even if recovery is possible.
I am using iText7 7.0.4 .
This actually is a bug in iText 7 creating an incremental update to a hybrid-reference file.
The error situation
Unfortunately the description in the question did not clearly describe a way to reproduce the error. Thus, the error can be reproduced like this:
Stamping the OP's sample document in append mode (it does not need to be a signing use case).
This step does not yet create the error in question.
Stamping the output of step 1 again in append mode (again it does not need to be for signing).
In this step the exception
com.itextpdf.kernel.PdfException: Append mode requires a document without errors, even if recovery is possible.
occurs.
The PDF in question
The OP's PDF is special as it a hybrid-reference file. According to the PDF specification (ISO 32000-1) such a file
is readable by readers designed only to support versions of PDF before PDF 1.5. Such a file contains objects referenced by standard cross-reference tables in addition to objects in object streams that are referenced by cross-reference streams.
In case of these files the startxref offset points to the start of the pre-1.5 cross reference table and the trailer XRefStm entry points to the 1.5 cross reference stream.
The PDF specification furthermore dictates that
the XRefStm entry shall not be used in the trailer dictionary of the main cross-reference section but only in an update cross-reference section.
Therefore the funny looking construction in the file:
18 0 obj
<</Type/ObjStm/N 10/First 67/Filter/FlateDecode/Length 357>>
stream
[...object stream data...]
endstream
endobj
[...]
25 0 obj
<</Type/XRef/Size 25/W[ 1 4 2] /Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] /Filter/FlateDecode/Length 97>>
stream
[...cross reference stream data...]
endstream
endobj
xref
0 26
[...cross reference table with 25 entries, objects in object stream are marked free...]
trailer
<</Size 26/Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] >>
startxref
[points to the preceding cross reference table]
48341
%%EOF
xref
0 0
[...empty incremental update cross reference table...]
trailer
[XRefStm points to the cross reference stream in object 25]
<</Size 26/Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] /Prev 48341/XRefStm 48045>>
startxref
[points to the empty incremental update cross reference table]
49017
%%EOF
Thus, while funny looking, this construction is correct.
What goes wrong
When reading the original document iText 7 recognizes that the document contains both a cross reference table and cross reference stream and chooses the cross reference stream. (Actually PdfReader.readXrefSection first reads the empty cross reference table, then finds the XRefStm entry in the trailer, and then reads the cross reference stream.)
When creating the incremental update, iText 7 remembers that the source PDF has been parsed via a cross reference stream and, therefore, uses full compression, i.e. in particular it uses an object stream and a cross reference stream.
When creating that cross reference stream, though, it sets its Prev entry to what the final startxref of the original PDF pointed to, i.e. the empty cross reference table, and not the cross reference stream it actually used.
Such mixed constructs (a cross reference stream pointing to a cross reference table as Prev) are not allowed, though.
Thus, iText in step one created an invalid cross references structure in its result document and, therefore, in step two found a broken PDF to process and complained.
The document you are trying to change in append mode is broken. Most likely, the byte offsets as defined in the cross-reference table don't correspond with the actual byte positions of the PDF objects.
In your case, I see something strange at the end of the file:
xref
0 26
0000000010 65535 f
0000000017 00000 n
0000000166 00000 n
0000000222 00000 n
0000000492 00000 n
0000000755 00000 n
0000000932 00000 n
0000001180 00000 n
0000001233 00000 n
0000001286 00000 n
0000000011 65535 f
0000000012 65535 f
0000000013 65535 f
0000000014 65535 f
0000000015 65535 f
0000000016 65535 f
0000000017 65535 f
0000000018 65535 f
0000000019 65535 f
0000000020 65535 f
0000000000 65535 f
0000001961 00000 n
0000002154 00000 n
0000044863 00000 n
0000048000 00000 n
0000048045 00000 n
trailer
<</Size 26/Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] >>
startxref
48341
%%EOF
xref
0 0
trailer
<</Size 26/Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] /Prev 48341/XRefStm 48045>>
startxref
49017
%%EOF
You have a PDF with two trailers. One trailer claims that the cross-reference table in stored in a stream:
/XRefStm 48045
While at the same time indication the start of the cross-reference table at byte position 49017:
startxref
49017
The other trailer claims that there's an uncompressed cross-reference table and that it starts at byte position 48341:
startxref
48341
And indeed: there is an uncompressed cross-reference stream:
xref
0 26
0000000010 65535 f
0000000017 00000 n
Do you understand the inconsistency in your file?
When you use append mode, iText doesn't change anything to the original document: not a single byte is changed; new bytes are added after the final %%EOF marker of the original file. However, iText refuses to do this when the original file is broken. I hope you understand the rationale: you'd make a bad situation worse if iText allowed you to do this.
To solve this problem, you need to fix the broken file first. That can be done by "manipulating" the document without changing anything, but to do this in normal mode, not in append mode.
Have you tried removing the extra trailer. I threw away:
xref
0 0
trailer
<</Size 26/Root 1 0 R/Info 9 0 R/ID[<8812105F6F93284DAEF240C8C1FC4C4E><8812105F6F93284DAEF240C8C1FC4C4E>] /Prev 48341/XRefStm 48045>>
startxref
49017
%%EOF
Adobe Reader didn't complain after removing these bytes.
So, because this page has high ranking in search results for the error, but doesn't provide much in the way of recovery steps, I thought I posted how I got around this issue.
Given:
having received "broken" files from somewhere you don't necessarily control; and
needing to do something with those files
I've found that some operations in iTextSharp will force a recovery. This isn't exactly "clean", in that it modifies the file, but since you received this error you might care more for getting something done than being entirely correct to the specification of PDF.
The workaround is basically just to add an empty bit of text to the PDF. In my case, this let me continue processing the files I'd received.
public byte[] InsertEmptyText(byte[] file)
{
var customText = new CustomText();
customText.FontSize = 1;
customText.Align = TextAlign.Right;
customText.Text = "";
customText.StartingPointPosition = new System.Drawing.Point(50, 50);
customText.PageNumber = 1;
PdfInsertObject pi = new PdfInsertObject();
pi.LoadPdfDocument(file);
pi.AddText(customText);
return pi.InsertObjects();
}
Preceding the creation of the PdfReader with passing the data through this (and capturing the result) let me continue.
I have to provision over 30 QL420plus printers and I'm struggling with what I thought would be easy..
We are going to use the printers in conjunction with an in-house app we have written on Windows Mobile 6. Basically the app sends a stream to of CPCL commands to print a label. As the label has non-standard fonts we have created 7 CPF files that we need to put on the printer.
However the problem is that the new version of LabelVista (now called Zebra Designer v2.2.3) will not let you "Send a Font" like you could in the LabelVista that ran on Windows XP. You have to use the "Zebra Font Downloader". This is where the problem really comes home because it will not let you add a CPF file. You have to create a MMF file and then download it to the printer. This creates one big file which has the various fonts in it. This is pretty useless when the label format looks like this:
! 0 200 200 304 {8}
LABEL
CONTRAST 0
TONE 0
SPEED 3
PAGE-WIDTH 408
BAR-SENSE 50
COUNTRY UK
VT 7 0 280 220 {0}
VB EAN{13} 1 2 60 310 230 {9}
T Got08Bpt.cpf 0 5 3 {1}
T Got05Bpt.cpf 0 5 91 TICKET PRICE
T Got010Bpt.cpf 0 5 220 RETAIL PRICE
T Got012Bpt.cpf 0 5 240 {12}
T Got014Bpt.cpf 0 20 240 {6}
CONCAT 5 105
Got28Bpt.cpf 0 0 {10}
Got14Bpt.cpf 0 7 {11}
ENDCONCAT
FORM
PRINT
I need different font sizes for each text line written on the label, yet I can't download the CPF files individually to the printer.
I can't install the old verison of LabelVista becuase it won't let me install on Windows 7. I have read the CPCL Progrmaming guide from Zebra and that's ot helpful at all. Can anyone help or my Zebra account manager is going to have a really bad day. :-)
Thanks
Mike
Try the code I pasted here Sending a font file (.cpf) to zebra Qln320 printer over WLAN
I store font files in Oracle DB, load them to Windows CE device and send'em via BT to device. The only "bad thing" in this method is that printer off after each file downloading (buy the way when you load font file via USB from LabelVista the problem the same).
To delete file from printer you can use this String.Format("! U1 do \"file.delete\" \"{0}\"\r\n", FileName.ToUpper());
You can use "Zebra Setup Utilitites" to manage your printers. This software allows you to communicate with your printers and to configure them.
I want to be able to find out where the code appearing at the entry point comes from by looking at the PE header.
For example, this piece of code is the starting code of my program(401000h)
00401000 >/$ 58 POP EAX ; kernel32.76E93677
00401001 |. 2D 77360100 SUB EAX,13677
00401006 |. BB 4A184000 MOV EBX,<JMP.&kernel32.VirtualProtect>
I want to know where this code comes from. How can I find it without manually scanning my file? (to complete the example, here's an hexdump from the same file, the code now resides at 200h)
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000200 58 2D 77 36 01 00 BB 4A 18 40 00
How can I get from my virtual entry point (401000h) to the raw entry point (200h)?
I tried solving it myself of course. But I'm missing something. At first I thought:
.text[ Entrypoint (1000h) - VirtualOffset (1000d) ] = raw entrypoint
since the file alignment = 200, and the raw entry point was at the very start of my .text section, I thought I could use this for all the executables.
Solved, I made stupid mistakes when calculating the raw entry point
.text[ Entry point - Virtual offset ] + File Alignment = Raw entry point (relative to .text section)
To locate the offset in the file by yourself you need to have a look at the _IMAGE_NT_HEADERS structure. From this you can get the IMAGE_OPTIONAL_HEADER where
the member you are interested in ImageBase is. You can change its value with EditBin /REBASE so there is little need to roll your own tool.
For reference how you can determine the entry point via dumpbin.
You can use
dumpbin /headers
dumpbin /headers \Windows\bfsvc
Dump of file \Windows\bfsvc.exe
PE signature found
File Type: EXECUTABLE IMAGE
FILE HEADER VALUES
14C machine (x86)
4 number of sections
4A5BBFB3 time date stamp Tue Jul 14 01:13:55 2009
0 file pointer to symbol table
0 number of symbols
E0 size of optional header
102 characteristics
Executable
32 bit word machine
OPTIONAL HEADER VALUES
10B magic # (PE32)
9.00 linker version
DE00 size of code
2000 size of initialized data
0 size of uninitialized data
4149 entry point (01004149)
1000 base of code
F000 base of data
1000000 image base (01000000 to 01011FFF)
1000 section alignment
200 file alignment
For the entry point the image base value is relevant. But this is only true for images that are not ASLR enabled. For them a random base address (1 of 128 different ones) is choosen.
The flag that indicates if an image is ASLR enabled is the value 0x40 which is set in DLL characteristics.
8140 DLL characteristics
For svchost.exe for example it is set for older programs it is generally 0.
Yours,
Alois Kraus
Have a look at this thread including an answer with a detailed explanation: Calculating the file offset of a entry point in a PE file
AddressOfRawEntryPoint (in EXE file) = AddressOfEntryPoint + .text[PointerToRawData] - .text[VirtualAddress]
I am new to COBOL(and OpenCOBOL) and my question is about "complex-odo" (OCCURS...DEPENDING ON) in OpenCOBOL.
I used 1.0 on following code
......
01 W-PTDO-PROC-TBL.
05 W-PTDO-PROC-ENTRY OCCURS 0 TO 450 TIMES
DEPENDING ON W-PTDO-PROC-MAX
INDEXED BY W-PTDO-PROC-INDX.
10 W-PTDO-PROC-APC PIC X(05).
10 W-PTDO-PROC-LNSUB PIC S9(07) COMP-3.
10 W-PTDO-PROC-KEY.
15 W-PTDO-PROC-WA-OFFSET PIC 9(08)V99.
15 W-PTDO-PROC-UNITS PIC 9(09).
10 W-PTDO-PROC-DEVICE-CNT PIC 9(03).
10 W-PTDO-PROC-DARRAY OCCURS 0 TO 450 TIMES
DEPENDING ON W-PTDO-DARRAY-MAX
INDEXED BY W-PTDO-DARRAY-INDX.
15 W-PTDO-PROC-DHCPCS PIC X(05).
10 W-PTDO-DARRAY-SIZE PIC 9(03).
10 W-PTDO-PROC-TOT-DCHRGS PIC 9(10)V99.
10 W-PTDO-PROC-TOT-DUNITS PIC 9(05).
10 W-PTDO-PROC-USED PIC X(01).
......
and cobc returns with this error msg:
Error: 'W-PTDO-PROC-ENTRY' cannot have the OCCURS clause due to 'W-PTDO-PROC-DARRAY'
And above error msg is issued from field.c where I found this comment
/* the data item that contains a OCCURS DEPENDING clause shall not be subordinate to a data item that has the OCCURS clause */
Is there anyway to make OpenCOBOL support this "complex-odo"?
My above code snippet, with "OCCURS DEPENDING" nested under a higher level "OCCURS" clause, seems to be a well-defined "complex-odo" according to appendix of IBM's COBOL Programming Guide.
Thank you,
Billy Rong
You cannot have a variable length array (OCCURS DEPENDING ON) inside another array!
The processing required is just too complex. If the length of the inner array item was allowed to vary, the only possible way to calculate the start of the Nth entry of the outer array is to sequentially access each inner member from 1 to N and use the DEPENDING ON count to work out its length, and, hence the start of the next array entry.