These are chat archives for highfidelity/hifi

11th
Feb 2015
David Rowe
@ctrlaltdavid
Feb 11 2015 18:06
2D text overlays currently can't have their background colour and alpha successfully set. Is this a known problem?
(Their background is always displayed as a dark semitransparent grey.)
David Rowe
@ctrlaltdavid
Feb 11 2015 18:17
Also, text size calculations are no longer correct.
Brad Hefta-Gaub
@ZappoMan
Feb 11 2015 18:18
@ctrlaltdavid - can you give more specifics and examples
a PR just got merged that should fix quad coloring… and a PR got merged yesterday that should have fixed text color
as for sizing calculations… more details are needed…
David Rowe
@ctrlaltdavid
Feb 11 2015 18:21
Was having these problems with Windows 1923 ... Just wanted to see if were already being worked on. Will retest with latest once things are back up and running again then provide details.
Brad Hefta-Gaub
@ZappoMan
Feb 11 2015 18:22
background color for quads have potentially been broken for a couple weeks… the color was not being considered in the cached geometry… so if color changed but shape didn’t… you’d get bad colors.
that was fixed yesterday. merged this morning.
Ryan Huffman
@huffman
Feb 11 2015 18:28
re: text size calculations, I imagine this is because TextOverlay::textSize was not updated when TextRenderer was updated
Brad Hefta-Gaub
@ZappoMan
Feb 11 2015 19:08
@ctrlaltdavid - looks like there is a bug related to quad colors when there are multiple quads with different colors… I’m looking at it now.
Joe Large [Omega Heron]
@OmegaHeron
Feb 11 2015 19:18
Will text entities allow for "extended" characters like ©?
Brad Hefta-Gaub
@ZappoMan
Feb 11 2015 19:18
they should… with the newest font code
Joe Large [Omega Heron]
@OmegaHeron
Feb 11 2015 19:19
Let me try again - I'm on windows 1926 now
Inserting © into string yields...
hifi-snap-by-OmegaHeron-on-2015-02-11_14-19-59@1005-3_76-7975_1010-58.jpg
does it need to be escaped somehow vs pasting it in?
Bradley Austin Davis
@jherico
Feb 11 2015 19:39
@OmegaHeron The core text renderer code definitely supports extended like that (as long as they're in the underlying font). However, I've been unable to get non-7-bit ascii characters to work via modifying the entity properties. I'm concerned that the issue is how the text input is read out of the edit field, or possibly how the data is persisted.
the text renderer code expects a QString, which it then iterates over, grabbing QChars
Ryan Huffman
@huffman
Feb 11 2015 19:41
I think it's how the data is persisted, it works fine for overlays
Bradley Austin Davis
@jherico
Feb 11 2015 19:42
however, all of the code passing to the text renderer is probably still passing null terminated c strings.
I don't know what encoding Qt assumes when converting const char * to QString
Joe Large [Omega Heron]
@OmegaHeron
Feb 11 2015 19:43
thanks - I know for a while I could make multi lines on windows builds using \n - but at some point that went away now displaying \n vs linebreaking.
Brad Hefta-Gaub
@ZappoMan
Feb 11 2015 19:45
the data is persisted using the qPrintable() macro… so that very likely does strip out non-ascii characters… we could definitely change that to simply treat it like a raw buffer of bytes.
David Rowe
@ctrlaltdavid
Feb 11 2015 19:47
@ZappoMan Yes re multiple quad colours bug: If I have stats displayed background of text overlays isn't rendered properly.
Joe Large [Omega Heron]
@OmegaHeron
Feb 11 2015 19:49
@ctrlaltdavid - I've seen that too, but it's intermittent. With stats on sometimes my text entities take on random colors - it's really hit and miss for me though and haven't seen it happen today. Hoped that had been fixed in today's updates.
Bradley Austin Davis
@jherico
Feb 11 2015 19:55
I also need to fix the space handling. I've noticed that the current code treats multiple spaces as a single space, so the info overlay doesn't line up the way it used to be.
Joe Large [Omega Heron]
@OmegaHeron
Feb 11 2015 19:56
Parsing \n would be nice to have back as well, if possible.
Brad Hefta-Gaub
@ZappoMan
Feb 11 2015 19:57
@jherico - that behavior was introduced with your SDFF font rendering checking - I’ve filed a bug on the topic (in a new internal bug tracking system we’re testing out)… I did switch some stuff to use non-breaking space to get around that behavior.
when I say “stuff” I mean some of the stats rendering (the performance details) which was impossible to read when the spaces were removed.
Bradley Austin Davis
@jherico
Feb 11 2015 20:01
Do you mean in the entity editor text input? Because the text renderer supports line feeds.
but I'm guessing that qprintable would strip that out as well.
Brad Hefta-Gaub
@ZappoMan
Feb 11 2015 20:02
I’m pretty sure qPrintable leaves in line feeds. The qPrintable seralization has been used since day 1 so if it “used to work” then that hasn’t changed.
this is definitely a tricky discussion only because there are several pieces that each may support special characters differently...
for example, you’ve got the JS/HTML based tools for setting properties… then you’ve got the JS to C++/QString layer pass those properties… then you have the serialization of QString over the wire and ultimately saved to disk (same code for both those).
Bradley Austin Davis
@jherico
Feb 11 2015 20:04
I think fixing the spaces might be as simple as changing str.split(" ", QString::SkipEmptyParts) to str.split(" ") in TextRenderer.cpp, but I haven't tested yet.
Brad Hefta-Gaub
@ZappoMan
Feb 11 2015 20:04
I can say for certain (since I just looked at the code) that the serialization code will only support “ascii” because of the qPrintable() call.
Joe Large [Omega Heron]
@OmegaHeron
Feb 11 2015 20:13
In placing a text entity as an object in world - then using the edit entity toolset - it does not support the extended characters or using \n as a line break at this time. This is via Windows Interface builds.
That's what I'm referring to specifically. :)