Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 10 hrs, 58 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 23 hrs ago - more...
cicer |
2010-10-19
, 21:18
|
|
Posts: 8 |
Thanked: 2 times |
Joined on Jul 2010
|
#561
|
It seams that it doesn´t support written accents. Instead of an "á" or an "ó" it displays an square. Is it my problem or an issue with the program.
|
|
2010-10-19
, 21:20
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#562
|
Originally Posted by mrsellout
Glad you like it
This is yet another great app for the n900. I've been using it for a few months now and it keeps getting better and better and I want to say thanks... THANK YOU!
Originally Posted by mrsellout
Hmm, interesting. Really the pipeline should be stopped if the shutter is closed, I'll have to talk to Dragly about this as he's the OpenGLES guru.
Right you asked for feedback and I'll provide. Yes it does startup quicker. It does feel smoother and the scan on request feature is great. There is one slight issue with the new build though. On startup the display gives a high fps reading (~70fps) until one opens the camera shutter. Now I don't open the shutter first because that loads the camera app, and sometimes it's a while before I actually use the app after starting it. I use this app in conjunction with PresenceVNC so I can copy the barcode into a proprietory Windows application. Sometimes the program needs to be started up and logged into. And sometimes a customer comes into the shop and I have to put the phone down and serve them, all before realising that I've not opened the shutter. So you can understand my concern.
Originally Posted by mrsellout
Sure, that should be reasonably easy to implement. I'll take a look at it for you (and I also find it a pain to click the shutter button with the screen open while testing tbh!)
One more thing if I may, can you enable the scan to be activated by the spacebar? I tend to use the app with the keyboard open and it's not that easy using the shutter button with the screen up.
This is still a fantastic app even with the little issues.
Thanks again,
mrsellout
|
|
2010-10-19
, 21:21
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#563
|
Originally Posted by cicer
The program I imagine. I'll need to check whether the backend supports accented characters or if it's simply a problem with the data being passed through mBarcode. Do you have an example handy for me to test on?
It seams that it doesn´t support written accents. Instead of an "á" or an "ó" it displays an square. Is it my problem or an issue with the program.
| The Following User Says Thank You to lardman For This Useful Post: | ||
|
|
2010-10-20
, 09:47
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#565
|
ZXing generates this output (http://zxing.org/w/decode):
A á
E é
I Ã*
O ó
U ú
and mBarcode generates something with similar end symbols (look at the terminal output. Ignore the fact that on some line most of the data are turned into delta characters, this seems to be caused by not using qPrintable() but instead using the stream operator to send the text to qDebug().)
So the question is really, what sort of encoding does the barcode contain? Afaiu, both libzbar and libdmtx should accept UTF-8, and it is possible to specify this at the beginning of the barcode. See this comment: http://sourceforge.net/tracker/?func...36&atid=928516
Basically it's going to take some more digging I think to work out whether the fault lies with the data (not saying what encoding it uses), the decoders (not guessing correctly or not handling the particular encoding in the data) or mBarcode (loosing the encoding along the way).
We specifically generate the QStrings that pass the data around using .fromUtf8(), so I think we should be handling it correctly. I'll see if there's a way of forcing the decoders to always assume UTF-8 in the absence of any other indicators.
A á
E é
I Ã*
O ó
U ú
and mBarcode generates something with similar end symbols (look at the terminal output. Ignore the fact that on some line most of the data are turned into delta characters, this seems to be caused by not using qPrintable() but instead using the stream operator to send the text to qDebug().)
So the question is really, what sort of encoding does the barcode contain? Afaiu, both libzbar and libdmtx should accept UTF-8, and it is possible to specify this at the beginning of the barcode. See this comment: http://sourceforge.net/tracker/?func...36&atid=928516
Basically it's going to take some more digging I think to work out whether the fault lies with the data (not saying what encoding it uses), the decoders (not guessing correctly or not handling the particular encoding in the data) or mBarcode (loosing the encoding along the way).
We specifically generate the QStrings that pass the data around using .fromUtf8(), so I think we should be handling it correctly. I'll see if there's a way of forcing the decoders to always assume UTF-8 in the absence of any other indicators.
| The Following User Says Thank You to lardman For This Useful Post: | ||
|
|
2010-10-20
, 11:49
|
|
Posts: 1,418 |
Thanked: 1,541 times |
Joined on Feb 2008
|
#566
|
Confirming that the new mbarcode version from Extras-Devel is way more responsive now.
|
|
2010-10-20
, 12:07
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#567
|
I've just pushed a very minor update to extras-devel which implements focus+scan for 5sec if you press the space button as mrsellout requested.
I've also worked out why the DBus and PythonQt plugins weren't working (my not using QDir very well) and will do some testing to see if I can get these up and running asap. Nothing in Extras-* for these, but they are sat in SVN if anyone wants to take a look.
I've also worked out why the DBus and PythonQt plugins weren't working (my not using QDir very well) and will do some testing to see if I can get these up and running asap. Nothing in Extras-* for these, but they are sat in SVN if anyone wants to take a look.
| The Following User Says Thank You to lardman For This Useful Post: | ||
|
|
2010-10-20
, 12:39
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#568
|
I'll try to get around and fix the fps startup issue. I just haven't found the error in the code yet. I think it could be solved by checking the shutter state one more time.
About the characters, this was something I looked into earlier. The problem is that ISO-8859-something or UTF-8 is usually the encoding used for qr codes, but there is no default encoding in the specification, so everything, including UTF-8, might be used.
In other words, if there is no information about the character encoding used by the qr encoder, there is no way to know what it is. I suggest we go with assuming UTF-8, as it is most universal, unless there are any encoding hints in the code.
About the characters, this was something I looked into earlier. The problem is that ISO-8859-something or UTF-8 is usually the encoding used for qr codes, but there is no default encoding in the specification, so everything, including UTF-8, might be used.
In other words, if there is no information about the character encoding used by the qr encoder, there is no way to know what it is. I suggest we go with assuming UTF-8, as it is most universal, unless there are any encoding hints in the code.
__________________
dragly.org
dragly.org
|
|
2010-10-20
, 12:41
|
|
Posts: 252 |
Thanked: 252 times |
Joined on Nov 2009
|
#569
|
But we could of course add an user option to change the encoding in case we get it wrong. Or somehow try to "guess" the encoding, if that is at all possible?
__________________
dragly.org
dragly.org
|
|
2010-10-20
, 12:44
|
|
Posts: 2,102 |
Thanked: 1,309 times |
Joined on Sep 2006
|
#570
|
Originally Posted by dragly
Ok, cool.
I'll try to get around and fix the fps startup issue. I just haven't found the error in the code yet. I think it could be solved by checking the shutter state one more time.
Originally Posted by dragly
We need to do some testing with popular encoders to see what they use, but yes I'd go for UTF-8 as the default as it's the obvious choice for encoding the barcodes (let's hope it's as obvious to those who write the barcode encoders!
About the characters, this was something I looked into earlier. The problem is that ISO-8859-something or UTF-8 is usually the encoding used for qr codes, but there is no default encoding in the specification, so everything, including UTF-8, might be used.
In other words, if there is no information about the character encoding used by the qr encoder, there is no way to know what it is. I suggest we go with assuming UTF-8, as it is most universal, unless there are any encoding hints in the code.
)Dragly, any thoughts on giving an indication (e.g. colour the list item) in the ResultsWindow sink list so that users know their tap has been registered?
