jimevins / glabels-qt

gLabels Label Designer (Qt/C++)

Home Page:http://glabels.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Import of glabels files

hochwasser opened this issue · comments

Hello,

I made a first try of an import of glables files.
It imports the Text-Node and image-Nodes. The gdk-pixmap is imported without a visible problem. The text is in the wrong size but i havn't figured out what the problem is.
Attached is a patch, with my try. hope this helps.

Thanks for your work.
Here is my patch: glabels-import.zip

I haven't really looked this over closely yet. But I do have one note: I would like to have a separate compatibility parser that doesn't taint the current parser. That is, the following lines in XmlLabelParser.cpp:

    QString version = XmlUtil::getStringAttr( node, "version", "" );
    if ( version != "4.0" )
    {
        qWarning() << "TODO: compatability mode.";
    }

would become the following:

    QString version = XmlUtil::getStringAttr( node, "version", "" );
    if ( version != "4.0" )
    {
        return  XmlLabelCompat3Parser::parseRootNode( node );
    }

where XmlLabelParserCompat3Parser would be largely the same as XmlLabelParser. However, it should keep both parsers more coherent.

Hello Jim Elvins,

thanks for your quick answer. I needed some time to port this into its own class.
I'm not happy with this solution, but it is a start.
In the zip you find a new class for the import of the 0.4 version.
model_import.zip
It would be nice to have a interface for the import and so put stuff that both file formats use (affine transformation, shadow...) into a base class.
For the pixdata: the import of image data works kind of. But it not "nice". Do you know methods in QT to read data in network byte order?

I ask my self also: why do you not use the QGraphicsView? What I read in the documentation it would be a perfect fit.

Hello Jim Elvins,

I revised my code. Some attributes have changed there values. So I made a copy of some XMLutils functions. I think they are to special and would be more appropriate in the parser class also for the default file format of the qt variant.
The problem with the network byte order I used the QDataStream class. This seems to work fine.
There should be more checks if the file is damaged though.
I'm interested what you think so far.

model_import.zip

Hello Jim Elvins,
I cloned your repository and added my changes: https://github.com/hochwasser/glabels-qt/commit/70aba68ebf2f7f97447464322559d7a91fe38638
This should make it easier for you and it should now conform to your style.
This is really challenging and exciting :-)

What I find strange: The text position. The position in my test file is set to top but it seems as if it is aligned bottom. Also in the GUI I think it is reversed. Is this a bug?

A little history of the versions of the glabels XML file formats.

  • 0.4.x was the last unstable version that was meant to lead to a stable 1.0 version based on gtk-1. This never happened, we skipped to 2.0 directly to align with gtk-2. The last release was in 2002 -- I don't know if it would be practical to try to reproduce test data -- I know I don't have any. It would be very unlikely to find any such files in the wild and is probably not worth trying to parse.
  • 2.0 was the first stable version of glabels which came out in 2004. 2.0, 2.2 and 3.0 files are largely compatible, each being a super set of its predecessor. 3.0 is the current format used by glabels-3.4.1. We can easily create test-data for it.

I am not sure about your vertical alignment issue -- it seems to work for me correctly.

I will try to kick the tires on your repository this weekend.

On which dtd should I base my parser then? In the templates directory (https://github.com/jimevins/glabels-qt/tree/master/templates) are two files.
The parser I made fits the GTK version of glabels from debian testing pretty well.

I'm still learning git and github so my code is in the master branch for the import.
https://github.com/hochwasser/glabels-qt/commits/master
I'm working on importing more than one per with different formating.

It would be nice to get some feedback what I can improve or where I made false assumption.
Thanks for looking into it.

You should base your parser on glabels-3.0.dtd. This is the version corresponding to all previous stable versions of glabels (2.0.0 - 3.4.1).

glabels-4.0.dtd is for the new glabels-qt version.

Then I had used the correct dtd but the wrong version number.
In the repository is now a version with correct parsing of the text span.
I found in another repository some glabels files which I use to test.
What I found is:

  • The font size is to big
  • The text get strange rendered, to low for the boxes. Maybe this makes the top/middle/bottom strange
  • The barcode is to big and can not be scaled smaller. This seems really strange to me.
  • For the datamatrix backend I made a special case that the internal backend is used and not the extern lib

Could you maybe give me some clues where to look with the font, text and barcode issue?

  1. You are right, the font sizes in 3.0 were scaled incorrectly. So a scale factor here is expected.

  2. One thing I noticed is that text colors are getting changed. This appears to be from this line:

textColorNode.setColor(color);

Unfortunately, `TextColorNode::setColor() expects a QColor. C++ is automatically constructing a QColor using one of its constructors, which is not interpreting its input as a 32bit rgba value. You should be able to simply:

textColorNode = TextColorNode( field_flag, color, key );

Otherwise we would need to overload an appropriate version of setColor()

  1. Another thing I noticed is that text with either w or h set to zero doesn't show up. This is because glabels-qt now uses a box model for text. I.e. the text box will not autosize when zero as in previous versions. When encountered in this case, we should attempt to size it appropriately. There may also need to be some adjustment to all text boxes because of different margins and differences in how text is layed out (I don't know I haven't really investigated). If we don't get this perfect, it's not the end of the world -- we just need it to be reasonably close.

  2. I don't really like the idea of changing the barcode backend on the user. Again, we don't need to get this perfect -- just reasonably close. If a barcode is not scaling smaller, this is because it is probably already at its minimum size.

  1. Yes. The multiplier seems to be 0.75. I have added this.
  2. I have corrected the error and changed the interface for setColor to explicit.
  3. I have to look into this. What I found: When the margin is removed from the y axes to set the Text it fits "more". Why is there a marginPts and why is it hard coded?
    4.1 If this bothers you I can make a message box and ask the user if he wants this translated. I think a dialog at the end of the import would be nice to inform the user what could be imported and where problems are.
    4.2 The scaling bothers me more. In the old version it was possible to make the barcode smaller. So why is this not possible in the new version? Datamatrix codes can be as small as 2-3mm²

Why is there a marginPts and why is it hard coded?

This is so that the text is not obscured by the text box selection. It is hard coded to keep the user interface simple -- there really is no reason to expose this to the user since the text box is never actually printed.

4.1 If this bothers you I can make a message box and ask the user if he wants this translated. I think a dialog at the end of the import would be nice to inform the user what could be imported and where problems are.
4.2 The scaling bothers me more. In the old version it was possible to make the barcode smaller. So why is this not possible in the new version? Datamatrix codes can be as small as 2-3mm²

My bad. I had forgotten that I did not include a backend for the datamatrix library. You WILL need to convert to the built-in implementation in this case, afterall

The minimum size is determined by the minimum cell size defined in glbarcode/Barcode2DBase.cpp:

	const double MIN_CELL_SIZE  = ( 0.0625 * PTS_PER_INCH );

This may be too big, but there does need to be a practical minimum cell size. Feel free to change this for now. I will probably eventually do some refactoring so that this value will be code type dependent and can be based on each code's spec, which is the case for 1D codes.

Before I go on, what would be needed to get the parser included into your git?
I think it would be best to get this done and then go from there on :-)

Create a pull request. I expect that there may still be a little back-and-forth before I merge.