Nasty table behavior (bug?) in FM 7.1 (structured)

Hello,
I have found that an Import => Element Definitions... command changes paragraph styles in tables.
Here what I've done (all in structured FM 7.1 WinXP):
1. opened new doc based on template.
2. added two identical tables - formats came from template:
- 1 head row (white text, black background),
- 2 body rows (black text),
- 3 cols in every row.
3. typed some text in header row and in body rows.
4. put cursor in second table, selected and applied (to selection) another format via Table Designer.
5. run File => Import => Element Definitions... from template (the same one I've used in step 1)
6. RESULT: all para styles in second table became Body; table where original format was not changed kept the original styles.
Does anybody knows how to deal with it? Template/EDD problem?
Thanks
Slava

Slava,
Since the table is part of a structured flow, importing element definitions may indeed affect its formatting.
If the new element definitions do not contain format rules that apply directly to the content of your table cells, the formatting of the cells is determined by the table format. In particular, the information in the table format includes the paragraph format used for each cell in the first row of each of the three parts of the table (heading, body, and footing) in the table from which the format was created (or updated). Since an actual table may have more columns than stored in the table format, FrameMaker's default behavior is to apply the paragraph format stored in the table format for the first cell in the row associated with that table part.
Your two tables have different table formats. If different paragraph formats are stored in the two table formats, then, yes, importing element definitions will apply different paragraph formats to the cells in the two tables.
--Lynne

Similar Messages

Question on Light Table behavior

I am wondering if it just me and a couple of others who are seeing pixelated images in a Light Table in 3.1.1?
Situation:
With Aperture 3.1.1 set to all defaults in Preferences, I create a new light table (either empty or with pre-selected images) and then drag images to the light table.
The images are small on the table. They appear to be lower quality than the images in the filmstrip to begin with. Resizing the images exagerates the problem and reveals unclear and/or pixelation.
I have done a clean install of Aperture 3 and updated to 3.0.3 and the issue does not exist. Light Table images are fine whether resized or not.
*What I have tried so far:*
1 - Clean install of OS X 10.6 and updated with 10.6.6 combo installer (repaired disk permissions once installed), then install Aperture 3 and updated to 3.1.1 (repaired disk permissions once completed). Import new images from Nikon D80 (both RAW and JPEG) and tested light table. Same issue. Then imported new .cr2 files from a friend's Canon, which all had the same issue.
2 - Copy APTS lesson files and library to drive > open with Aperture 3.1.1 (upgrade library when prompted). The existing images in that library behave correctly in Light Table, but newly imported images into that library display the image degradation / pixelation in light table.
3 - In all cases, I have tried to delete / generate Previews as well as Thumbnails. None of these have sorted the issue.
Note - it almost appears to me that the images used on the light table are actually small thumbnails that are low quality on the light table and any subsequent resizing pixelates the image.
Note #2 - the strange thing in all cases is that using the loupe tool and panning over the images in the light table shows high-quality image.
I am trying to determine if it is my machine (or procedure) specifically, or if there are others experiencing this in large numbers.
I have 8 GB RAM and the nVidia 8800 GT upgrade card in my machine. Whether just Aperture 3.1.1 is installed or with all my normal software, no difference in Light Table behavior.
Looking for comments as to whether users have no issues like this or any who do.
I have already sent a report to Apple.
Thanks in advance for any comments.
Corky

SP,
I do not think this is intended behavior, as it works as expected in AP 3.0.3.
I sent a bug report via the feedback function in the Aperture menu and will follow up with a second one. I was hoping that other users would chime in as to whether they were experiencing the issue, or if it is working correctly on their system. Unfortunately, there has been no response other than yours as you can see.
There are two other threads since the release of 3.1.1 where 3 or 4 other users are having the same issue (at least as far as the pixelation / low resolution image issue).
On my system, the default size of the light table changed between 3.0.3 and 3.1.
In 3.0.3 the light table starts off smaller (with larger grid squares as if zoomed in) and dragging the images onto the table show the same quality image on the table as in the filmstrip. In 3.1 (and 3.1.1) the light table starts off much larger (with smaller grid squares as if zoomed out) and dragging an image from the filmstrip results in a smaller sized thumbnail showing on the light table at the lower quality.
I have also been going back through the 'Apple Pro Training Series - Aperture 3' book using the included library and lesson files (to test for functionlity with AP 3.1.1 and iPhoto '11) and I find that in lesson 3 where the light table is used, the same issue appears once you resize one of the images next to smaller images (which results in the three smaller images being lower quality than the resized image).
My guess is that the thumbnail / preview function connected with the light table sizing is creating an issue where the light table is using a smaller thumbnail when it should be switching to (or using from the beginning) a preview for quality. The fact that the image viewed under the loupe tool is high quality lends to this theory - IMHO.
I am hoping that this is fixed in 3.1.2 (if they release an update), since I would like to use the light table for layout decisions and for comparing multiple images. The bad image quality sort of shoots this function in the foot for me.
The only real fix is to revert to AP 3.0.3 and forego the 3.1.1 improvements which really isn't a fix.
To any others reading this post, could you please indicate whether the light table image quality is fine for you or whether you are experiencing the bad quality / pixelation issue I am? It would help me in discovering whether this is machine (hardware) specific or a wider issue.
Thanks in advance for any help.

LiveCycle Designer 8.0 Table Header bug

My dynamic form (8.0 dynamic XML form) has strange behavior with table headers.
When rows are dynamically added to the table to make the table expand to a third page, the table headers become unstable. Once the table expands to the third page, if a row is added or removed, a new table header is added to the second page so the second page ends up having extra table headers.
I have been using LiveCycle Designer 8.0 that came with Acrobat Professional 8.0.
I have been using the Purchase Order.pdf, that came with Designer 8.0, as an example to create tables that can have rows added or removed dynamically. I checked the Purchase Order.pdf (8.0), and it also has the same buggy, table-header behavior.
I then downloaded Acrobat Professional 9.0 which comes with LiveCycle Designer 8.2 and checked the Purchase Order.pdf that came with it.
The Purchase Order.pdf (8.2) works correctly.
I then compared the timestamps of the Purchase Order.pdf (8.0) and Purchase Order.pdf (8.2) and their XML source.
The timestamps are different, Purchase Order.pdf (8.0) -10/17/2006 11:16 PM, Purchase Order.pdf (8.2) -5/23/2008 1:16 AM.
The main difference in the XML source between the two versions is their
Overflow-related tag.
The Purchase Order.pdf (8.0) has
The Purchase Order.pdf (8.2) has .
I dont know about Designer 8.1, but the table-header bug is definitely fixed in Designer 8.2.
Could someone please tell me what I need to install to fix this bug? Is there a service pack for Designer 8.0 or do I have to install Designer 8.2?
I have seen workarounds for this bug in the forum, but creating a master page containing the table header for each table in the form seems to be an excessive hack.
Thanks,
Mike

There is no patch .....if it is fixed in 8.2 then you will have to use that.

Finder's Nasty Inherited ACL Bug (aka Error -41)

CNET, MacFixit, and a few other technical blogs recently reported on an apparent ACL issue which seems to have existed in OS X Snow Leopard since OS X 10.6.0, but has gotten particularly bad in OS X 10.6.5, 10.6.6, and 10.6.7 (both client and server versions). The symptom is that when inherited ACLs are present in an OS X 10.6.x system, it's possible to overflow the ACLs with "crud" (unwarranted extraneous ACEs) by performing simply copy / clone operations in the Finder, AppleScript and other "Finder-like" programs that can eventually overflow the 128 entry limit per ACL.
In reading the original posters postings (www.brunerd.com/blog/2011/03/22/finders-nasty-inherited-acl-bug-aka-error-41/ and openradar.appspot.com/9160099) I got really worried about our production OS X servers, but after some experimentation discovered a happy accident: it’s quite easy to overflow ACLs when performing repeated copy or duplicate operations on folder hierarchies on locally attached filesystems (whether attached on a client or server), but in actually it's much harder to make that happen with AFP-mounted filesystems having to do with a slower growth curve of the "crud" that develops as users copy / duplicate folders.
Since ACLs tend to be fairly rarely deployed on OS X client systems, you also don't tend to run into the problem (I point out Drop Boxes as a possible exception), but IT administrators can run into this problem quite easily when cloning fairly deep server-side folder hierarchies in the Finder on an OS X Server.
If your users are encountering "Finder -41" errors when performing seemingly simple operations in the Finder, this type of ACL overflow may be explanation. You might want to read up on the thread developing at www.brunerd.com/blog/2011/03/22/finders-nasty-inherited-acl-bug-aka-error-41/ for further details.

This has been an ongoing issue since 10.6.5. See this thread: http://discussions.apple.com/thread.jspa?threadID=2686643&tstart=0
The only real fix is to downgrade the clients to 10.6.4. What I've been doing is reapplying the ACL's from the server admin tool after each tape rotation. That way I'm not using up extra tapes since NetVault will back up the files again if the ACL has changed. The other thing I have some users doing is opening up the file they want to copy and doing a save as to the destination. That way doesn't seem to duplicate the permissions.

Jdev 11 Table validations bug.

Validation errors on ADF editable table fires only when you change a row by clicking.
If you press any submit button they disapear.
Also validations dont fire if you navigate to a diferent row by pressing Tab key.
is this a bug?
Is there any way that these validation errors do not disapear when i press any button?
details:
[http://adfbugs.blogspot.com/2009/08/table-validations-bug.html]

Hi,
don't think this is a bug because you perform sever side validation that is not existing on the client. So this validation only happens when you change the row currency on the binding layer, which is not happening when you use the tab. To see this error immediately you would need to assign a submit event when leaving a filed. So if you set autosubmit=true on your cell component renderers then this fires quite happily (but who wants to pay the price for this ?)
Frank

SE16 for tables, what to use for looking into structures

Hi,
I want to check a structure field for 700 materials on contents. I don't have a report to check them and I would like to check them in the same way as you can check table-fields with SE16. Is this possible?
Willem-jan Bos

Dear Willem-jan Bos,
It is <b>not possible</b> to see the data in structures as they do not store the data. You can only see the data of tables and views in SE16/SE11. Structures are used in tables or in programs. They never store the data.
Regards,
Naveen.

External Table - possible bug related to record size and total bytes in fil

I have an External Table defined with fixed record size, using Oracle 10.2.0.2.0 on HP/UX. At 279 byte records (1 or more fields, doesn't seem to matter), it can read almost 5M bytes in the file (17,421 records to be exact). At 280 byte records, it can not, but blows up with "partial record at end of file" - which is nonsense. It can read up to 3744 records, just below 1,048,320 bytes (1M bytes). 1 record over that, it blows up.
Now, If I add READSIZE and set it to 1.5M, then it works. I found this extends further, for instance 280 recsize with READSIZE 1.5M will work for a while but blows up on 39M bytes in the file (I didn't bother figuring exactly where it stops working in this case). Increasing READSIZE to 5M works again, for 78M bytes in file. But change the definition to have 560 byte records and it blows up. Decrease the file size to 39M bytes and it still won't work with 560 byte records.
Anyone have any explanation for this behavior? The docs say READSIZE is the read buffer, but only mentions that it is important to the largest record that can be processed - mine are only 280/560 bytes. My table definition is practically taken right out of the example in the docs for fixed length records (change the fields, sizes, names and it is identical - all clauses the same).
We are going to be using these external tables a lot, and need them to be reliable, so increasing READSIZE to the largest value I can doesn't make me comfortable, since I can't be sure in production how large an input file may become.
Should I report this as a bug to Oracle, or am I missing something?
Thanks,
Bob

I have an External Table defined with fixed record size, using Oracle 10.2.0.2.0 on HP/UX. At 279 byte records (1 or more fields, doesn't seem to matter), it can read almost 5M bytes in the file (17,421 records to be exact). At 280 byte records, it can not, but blows up with "partial record at end of file" - which is nonsense. It can read up to 3744 records, just below 1,048,320 bytes (1M bytes). 1 record over that, it blows up.
Now, If I add READSIZE and set it to 1.5M, then it works. I found this extends further, for instance 280 recsize with READSIZE 1.5M will work for a while but blows up on 39M bytes in the file (I didn't bother figuring exactly where it stops working in this case). Increasing READSIZE to 5M works again, for 78M bytes in file. But change the definition to have 560 byte records and it blows up. Decrease the file size to 39M bytes and it still won't work with 560 byte records.
Anyone have any explanation for this behavior? The docs say READSIZE is the read buffer, but only mentions that it is important to the largest record that can be processed - mine are only 280/560 bytes. My table definition is practically taken right out of the example in the docs for fixed length records (change the fields, sizes, names and it is identical - all clauses the same).
We are going to be using these external tables a lot, and need them to be reliable, so increasing READSIZE to the largest value I can doesn't make me comfortable, since I can't be sure in production how large an input file may become.
Should I report this as a bug to Oracle, or am I missing something?
Thanks,
Bob

Undesireable Table Behavior After Patch 14582286 Installation

I'm running our application on a stand-alone instance of WebLogic with the ADF runtime. Here is a printout of of the opatch lsinventory:
[code]
Oracle Interim Patch Installer version 11.1.0.9.0
Copyright (c) 2011, Oracle Corporation. All rights reserved.
Oracle Home       : /u01/Oracle/Middleware/oracle_common
Central Inventory : /u01/Oracle/app/oraInventory
   from           : /u01/Oracle/Middleware/oracle_common//oraInst.loc
OPatch version    : 11.1.0.9.0
OUI version       : 11.1.0.9.0
OUI location      : /u01/Oracle/Middleware/oracle_common//oui
Log file location : /u01/Oracle/Middleware/oracle_common/cfgtoollogs/opatch/opatch2013-10-24_09-42-39AM_1.log
Patch history file: /u01/Oracle/Middleware/oracle_common/cfgtoollogs/opatch/opatch_history.txt
OPatch detects the Middleware Home as "/u01/Oracle/Middleware"
Lsinventory Output file location : /u01/Oracle/Middleware/oracle_common/cfgtooll
Installed Top-level Products (1):
Oracle Application Developer 11g                                     11.1.1.6.0
There are 1 products installed in this Oracle Home.
Interim patches (1) :
Patch 14582286     : applied on Tue Sep 17 14:29:09 EDT 2013
Unique Patch ID: 15506681
   Created on 19 Sep 2012, 10:02:46 hrs PST8PDT
   Bugs fixed:
     14582286, 13656274
OPatch succeeded.
[/code]
Before installing the patch, when saving items in a treeTable or table, the position of the table would remain after the save. Now, after applying the patch, anytime a save is performed, the table repositions automatically to the top row. This is not what we want to happen. Also I should note that we are only using ADF Faces with EJB; we are not using the full ADF stack (no business components).
Is this known behavior for patch 14582286? How can we correct this?
Thanks,
John

Frank,
Thanks for the reply. After the save/update, the selected row remains. Meaning, we can select a row, update a field in that row, then save. At that point, the table is repositioned to the very top. However, I can scroll back down to find that the row that was updated is still selected. I tried putting displayRow="selected" on the table component, but this did not seem to help.
I have not contacted support, as I would not have a test case to provide (this is an application that requires our database, and possibly the unique combination of patches applied to our server).
There is also another table in our application that is fairly simple, where we are not manually manipulating any row keys, and the same behavior is occurring.
If we did not previously have to take a snapshot of the selected rowkeys, what might have changed in that patch to make that a requirement now?
Thanks,
John

Switch Linked (xl source) Tables - behavior change Excel 2010 PP vs. Excel 2013 PP -- In 2013 all calcs of table are lost

Situation:
PowerPivot 2010 Model based on 10 linked tables (this tables are generated and refreshed as needed by SQL 2012 MDS Excel-AddIn)
Unfortunately Excel MDS AddIn changes sometimes the tablename (case: MDS Add-In Filter changed, MDS Server changed). So after Change of tablename we have to fix the powerpivot link to this Excel tables in powerpivot to get powerpivot refresh working again
Problem:
With Excel 2010 PowerPivot this was possible without big Problems. As Long as table has identical structure one can Change/Switch the table in powerpivot Windows > Ribbon "Linked" Table > DropDown "Linked Table X" or during update
via Dialog "Errors in Linked Table"
After upgrading the solution to Excel 2013 this is not possible any more without loosing any column- or measure calcs defined for this table! :( Every time you Change the assigned Excel table for an existing linked powerpivot table..you
get following Dialog:
"You are changing the source of X to Excel table Y. Changing the source will remove all formatting, measures, KPIs, hierarchies, and other Settings applied to the table. Are you sure you want to to continute?"
Does anyone found a Workaround for persisting existing calc of linked tables when changing the sourcetable (to another Excel table with same structure)??
Dear MS, this is IMHO really a step backwards and blocks the migration of our existing Excel 2010 PowerPivot Solution? Should i create a connect entry for that?!
Version-Info:
2010 Version: 11.0.3000.0 (PP Ribbon>Settings)
2013 Version: 11.0.2809.81 (Product version displayed for dll c:\program files\Microsoft Office\Office15\Addins\PowerPivot excel Add-In\PowerPivotExcelClientAddIn.dll)

There is a very similar issue discussed here where i tried to show the different behavior in terms of linked tables in Excel/PowerPivot 2010 vs 2013
http://social.technet.microsoft.com/Forums/en-US/8fd927f7-30fd-49b7-809c-cb1414955638/linked-tables-excel-2013-vs-2010-difference?forum=sqlkjpowerpivotforexcel
maybe it helps you to understand the issue
I assume that MDS creates a new table every time you refresh it thereby breaking the link to PowerPivot
in case you only have calculated measure you may created a separate, independent linked table and define all calculated measures there
this way they at least would not get removed
hth,
gerhard
Gerhard Brueckl
blogging @ http://blog.gbrueckl.at
working @ http://www.pmOne.com

Tables not in Query Builder table list bug?

In HTML DB version 1.6.0.00.87 we have tables defined in our schema in our workspace. When we create a view and click on the [Query Builder] link, no tables are in the drop down list for our schema. Why? The schema is there. I can go into the SQL Workshop and query the records our of the tables, but they are not listed in the [Query Builder].
I tried this same function but with my workspace at htmldb.oracle.com. The tables in my schema are listed there.
Is this a bug that was fixed in version 1.6.1.00.02?

There is one schema assigned to the workspace. That schema is listed in the pop-up window. Here are the steps I am doing:
1.) Click on SQL Workshop
2.) Click on Create Object
3.) Click on View
4.) The correct schema is listed in the Schema field. There is only one schema in the drop-down list for the Schema field.
5.) Click on [Query Builder]. A separate browser window appears with the correct schema. There is only one value in the drop-down list for the schema. "- Select Table -" is in the TABLE field.
6.) I click on the TABLE field to get a list of tables for the schema. Only "- Select Table -" is listed. No other tables are listed.
I can cancel the Create View and return to the main page of the SQL Workshop. I can click on Tables to see what table are available. I select the correct SCHEMA and see the list of tables.
I tried this in the same version of HTML DB (v 1.6.0.00.87) in a different database ie. a different HTML DB repository and received the same results, missing tables in the pop-up page
I do not know why the tables do not list in the [Query Builder] for the Create View.

How to squash a nasty screen blackout bug

Hi Mac experts,
I've been trying, without success, to squash a nasty Mac bug that causes my screen to black out during work or causes it to never wake up after sleep, the latter being more frequent. It's supremely annoying since it interrupts work a couple of times a week and, embarrassingly, happens more often during public presentations, possibly due to the 2nd screen. In some cases a single hard reset revives the MacBook, in others I have to reset several times for the screen to become accessible again. When the bug happens, the OS is still running (key feedback sound, keyboard backlighting can be adjusted) but the screen is completely black.
It's been an unfixed bug through several OS versions from 10.8, 10.9, to the latest 10.10 (Yosemite). The usual remedies suggested in forums did not work (see below). I'm out of ideas here, hopefully you are not.
My specs: MacBook Pro Retina 15'', purchased 2012.
My recent crash reports can be viewed here: https://drive.google.com/folderview?id=0B_EEMeI_SbKxMlZSVHhXdm1QZWs&usp=sharing
I have tried the following:
udpates did nothing; crashes under all OSs (10.8, 10.9, 10.10)
reinstalled 10.9 fresh and migrated my data; still bugged
startup in Safe mode (disables kernel extensions); crash on the same day
adjusting the energy prefs (disable switching, deactive all additional wake up conditions); did nothing
SMC and NVRAM resets did nothing
This is a bug shared by many users. Apple obviously is not fixing it. One user reported that in his specific case it wasn't a hardware issue. Replacing the motherboard did nothing (http://bit.ly/1E5cEAR). Here are some related reports: forums.macrumors.com/showthread.php?t=1722832 (2014-4; solution: detaching from ext. screen before sleep), discussions.apple.com/thread/6014780?start=0&tstart=0 (2014-03; not resolved), discussions.apple.com/thread/5665501 (2013-12, not resolved), discussions.apple.com/thread/5548226 (2013-11 to 2014, not resolved), forums.macrumors.com/showthread.php?t=1553654 (2013-03; solution: removal of Bresink driver), bit.ly/1wdVO1C (2012-8, problem w Bluetooth, fixed by OS update 10.8.1),..
I hope somebody has a suggestion. Looking forward to your expert insights.
All the best

skywalkr,
Have you taken some screen captures of the trap and dump information?
ThinkPads: S30, T43, X60t, X1, W700ds, IdeaPad Y710, IdeaCentre: A300, IdeaPad K1
Mark Hopkins
Program Manager, Lenovo Social Media (Services)
twitter @lenovoforums
English Community Deutsche Community Comunidad en Español Русскоязычное Сообщество

Need Help with Unusual Table Behavior

I've been asked to create a table with unusual behaviors, and I'm a little stuck on how to implement it. The table has cells with dates and blanks in it. The following rules need to work:
1. If the cell has a date in it, then:
a. If the user single-clicks on the cell, the cell should be selected. At most, the date could be highlighted and copied, but not changed
b. If the user double-clicks on the cell, a popup window should appear that allows entry of detailed data about the date. This overrides the default behaviors of entering edit mode on double-click.
c. If the user presses F2, the cell should enter edit mode and allow the user to edit or remove the date. This prevents the user from accidently changing an existing date, which is supposed to be a rare occurance anyway.
2. If the cell has no date, then:
a. If the user single-clicks a cell, double-clicks a cell, or uses the keyboard to navigate to a cell and then begins typing, the cell should enter edit mode and allow the user to enter a date. Once a valid date has been entered, the rules for #1 apply.
Optional:
The user can remove a date by clearing the date, but it would be nice if they could select multiple dates for deletion.
Any ideas would be appreciated. Right now, I'm stuck on how to make the cell editable with a single click depending on whether there is a date already in it.

Torgil wrote:
PatrickRThomas wrote:
Fair enough, but in all the topics I've seen on this site, I almost never see someone respond once they've been given an answer to their question. Why call me out on it and not everyone else?It's not just you. It's becoming more and more common actually. Here's an example from only yesterday (reply 3):
[http://forums.sun.com/thread.jspa?threadID=5340766]
Now, you may not like this, but the fact remains that this is how this particular forum works, and if you want help from the regulars here it's in your best interest to stick to the forum rules. Arguing about it almost never helps your case. (Personally I don't care much either way, but that's just me and as you can see from my posting history I'm not here very often so my opinion doesn't matter much.)
Finally, if you want help on JTables in particular, camickr is your man, so you might want to stay on his good side :-)In that thread you cited, it's fair to point out that the person never responded, but calling him a louse, etc. was uncalled for and unprofessional. If someone had politely said that I should reply to my other threads, I would have apologized and moved on. However, that's not what happened. I was called out in a way intended to humiliate me for 2 instances, not for my failure to reply, but for failing to reply quickly enough. That's what I found to be so ridiculous, and hence, my sarcasm. In the third instance, perhaps I should have responded with a "thank you" to the second response that I received. I'll take my lumps for that one. I also took offense to the suggestion that I only replied to my previous thread because I wanted help on this one. That was just a baseless accusation.
And for the record, the reason that I'm responding to this topic so quickly is that my email notifications are working this time. I do check my watchlist when I have a question that needs answering, but if I get pulled off onto another task, I may not check it for a while. I can't help that.

Link Behavior Bug in Motion 5

I've repeatedly defined a bevavior to two link colors together (a gradient colorize from one group links to the gradient colorize of another group.) I'll set it, it works just fine. When I close the project and open it up again, the "Apply To" is always reset and blank, but the Source Parameter will be intact.
Is there a known bug for this?
This in in Motion 5, which isn't available as a product option when submitting this discussion.

The behavior is being applied to the RGB colors of a Gradient Colorize filter, not the gradient itself. Correct, the gradient is made of multiple values (RGB colors, locations, opacity) so applying a behavior to the entire gradient doesn't even make sense, and rightly so is impossible to do.
So if you apply the Gradient Colorize filter to anything, select the first (or second) color in the gradient, then to the right of the color control (and dropper icon) you'll see the ability to apply a behavior. This color can be linked to any other RGB value in any other layer or group via a Link behavior.
However, in my case, when I do it.. it never saves.
I've run tests from scratch where it WILL save. There's something unique to this project that Motion doesn't like.. and for the life of me, I can't figure it out, other than to just call it a bug.
Here's the test file that I set up that does work:
http://www.mediafire.com/?qpxhdmjdlljns85
There's a source group and two linked groups that follow the source group. Changing the colors of the source group changes the colors of the other two groups. This one, for some reason, saves.
So, what the heck does that do for me? Nothing.. in fact it's worse. There's some sort of conflict going on that I need to find that keeps mine from saving properly.

Pages Table Formatting Bug in 10.10.3

Running pages 5.5.2 on MBP with OS X 10.10.3, i noticed this. I have a table on the same page as some text, and in order for the table (which was larger than 1 page) to fit I had to change the formatting to "always stay on page" and disallow text wrapping. In fact, the ONLY way to get the table to fit on the page was to change the paper type to legal size, so that the page was longer. Super lame, because now when I print it it will be distorted. That is a side issue however.
The main issue is with resizing the table columns, I noticed this happened. Essentially when moving the table's grid lines, the old formatting would remain, so there was a 'ghosting' effect. See this video for what I am talking about.
I tried saving it, then closing and reopening the file, and the 'ghosting' remained so I reverted to older version of the document to get it back. Resizing the table to original size manually also works. Here is a video clip of the bug: http://youtu.be/hZcx_HolJkI

Apple - Pages - Feedback

Nasty ID3V2 tag bug

This is for any of the Apple team. I discovered a pretty bad ID3V2 bug in iTunes for Windows, 6.0.4.2.
It has to do with the way the frame data length is encoded, or rather, in this case, not encoded. The result is that any tag data>127 bytes in length will likely break the entire tag.
The length of the data for a 2.4 version tag is the first 4 bytes after the ID field(TPE1, TIT1, etc). These bytes are syncsafe, meaning that the highest bit is always 0. So each byte actually encodes 7 bits. I had a frame that was 467 bytes in length. Its length was stored as "0x01d3". That equals 467. But it is supposed to be sync-safed, so it should actually be 0x0363. As a result, 0x01d3 actually decodes to only 211 bytes. When a tag parser jumps 211 to what should be the next tag, t'aint nothing there! So all subsequent frames are then lost.
This can get pretty nasty on Unicode tags which can then only store 64 characters before it breaks things.
iTunes and presumably the iPod and any other Apple supplied tools will probably read that data correctly as I am assuming they use a common library. But...it will break any third party tools. Not good.
Mac Mini Windows XP Pro

This is quite possibly the most annoying iTunes/iPod bug, and it's still kicking around in the latest iTunes version.
Note that all ID3v2 frames found in the tag prior to a frame with length greater than 127 bytes are read just fine. Once iTunes hits the syncsafe integer it gets lost.
ID3v2 frames can appear in the tag in any order. This means if you have a tag editor that lets you specify the order the frames appear in the ID3v2 tag and set it to put all frames which are "most likely" to be larger than 127 bytes (e.g. APIC, TIPL, TMCL), you can at least get iTunes/iPod to recognize a larger subset of the information. But granted, as you stated, that doesn't really help the unicode case.
Windows XP

Nasty table behavior (bug?) in FM 7.1 (structured)

Similar Messages

Maybe you are looking for